 From the CUBE studios in Palo Alto and Boston, connecting with thought leaders around the globe, these are Cloud Native Insights. Hi, I'm Stu Miniman, the host of Cloud Native Insights. And the thread that we've been pulling on with Cloud Native is that we need to be able to take advantage of the innovation and agility that Cloud and the ecosystem around it can bring, not just the location, it's not just the journey, but how do I take advantage of something today and keep being able to move forward? Happy to welcome back to the program, one of our regulars and someone that I've had lots of discussion about Cloud, Cloud Native serverless. So Corey Quinn, the chief Cloud economist at the Duckville Group. Corey, always good to see you, thanks for joining us. It is great to see me. And I always love having the opportunity to share my terrible opinions with people who then find themselves tarred by the mirror association. And that is certainly no exception to you, Stu. Thanks for having me back, although I question your judgment. Yeah, you know, what was that Pandora's box I opened when I was like, hey Corey, let's try you on video so much. And if people go out and they can look at your feed and you've spent lots of money on equipment, you have a nice looking setup. I guess you missed that one window of opportunity to get your haircut in San Francisco during the pandemic, but be it as it may. Corey, why don't you give our audience just the update? You went from a solo mentor of the Cloudverse to you now have a partner and a few other people and you're now a chief Cloud economist. Yeah, so it comes down to separating out what I'm doing with my nonsense from other people's, other people whose careers might very well be impacted by an ill-considered tweet of mine. When you start having other Clouds economists and realize, oh, okay, this is no longer just me we're talking about here. It forces a few changes. I was told one day that I would now be the chief Cloud economist, I smiled, shrugged, put on a backlog item to order new business cards because it's not like we're going to a lot of events these days. And from my perspective, things continue mostly a base. The fact that we're 10 people now means that there's things that my company does that I'm no longer directly involved with which is a relief to absolutely everything. But it's been an interesting ride. It's always strange. It's the number one thing that people who start businesses say is that if they knew what they were getting into they'd never do it again. I'm starting to understand that. Yeah, well, Corey, as I mentioned, you and I have had lots of discussions about Cloud, about multi-Cloud, serverless and the like. When you wrote an article talking about that multi-Cloud is a worse practice, one of the things underneath is when I'm using Cloud I should really be able to leverage that Cloud. One of the concerns that you and I did at KubeCon and CloudNativeCon is does multi-Cloud become a least common denominator? And a comment that I heard you say was if I'm just using Cloud and the very basic services of it, why do I go to an AWS or an Azure which have hundreds of services, maybe I could just find something that is less expensive because I'm basically thinking of it as my server somewhere else which of course Cloud is much more than that. So you deal with a lot of very large companies that help them with their bills. What differentiates the companies that get advantage from the Cloud versus those that just kind of fit in another location? Largely the stories that they tell themselves internally and how they wind up adapting to Cloud. If the reason I got into my whole spiel about why multi-Cloud is a worse practice is that I view best practices as sensible defaults. I view multi-Cloud as a ridiculous default. Sure there are cases where it's important and though I don't say, I'm not suggesting for a second that those people who are deciding to go down that path are necessarily making wrong decisions. But when you're building something from scratch with this idea toward taking a single workload and deploying it anywhere, in almost every case it's the wrong decision. Yes, there are going to be some workloads that are better suited in other places. If we're talking about SaaS and including that in the giant wrapper of Cloud, definition terms will always get you, then sure you would be nuts to wind up running on AWS and then decide you're also gonna go with code commit instead of GitHub. That's not something sensible people to use GitHub for God's sake. But what I am suggesting is that the idea of building absolutely every piece of infrastructure in a way that avoids any of the differentiated offerings that your primary Cloud provider uses is just generally not a great plan. Occasionally you need to, but that's not the common case and people are believing that it is. Well, I'd like to dig a little deeper. Some of those differentiated services out there, there are concerns but some that said, I think back to the PAS model, I want to build something, I can have it live anywhere but those differentiated services are something that I should be able to get value out of. So do you have any examples or are there certain services that you have as favorites that you've seen customers use and they say, wow, it's something that is effective, it's something that is affordable and I can get great value out of this because I didn't have to build it and all of these hyperscalers have lots of engineers building lots of cool things and I want to take advantage of that innovation. Sure, that's most of them, if we're being perfectly honest. There are remarkably few services that have no valid use cases for no customer anywhere. A lot of these solve an awful lot of pain that customers have. DynamoDB is a good example of this because that's one a lot of folks can relate to. It's super fast, it charges you for what you use and that is generally it or a provision model, great. But you don't have to worry about instances, you don't have to worry about scaling up or scaling down in the traditional sense and that's great. The problem is, is great, how do I migrate off of this onto something else? Well, that's a good question and if that is something that you need to at least have a theoretical Exodus for, maybe DynamoDB is the wrong service for you to pick for your data storage. Personally, if I have to build for a migration in mind and on no SQL basis, I'll pick MongoDB every time, not because it's any easier to move it but because it's so good at losing data that I'll have remarkably little of it left to migrate in the time comes. Corey, of course, one of the things that you help customers with quite a bit is on the financial sides of it and one of the challenges if I move from my environment and I move to the public cloud is how do I take advantage not only of the capability of the cloud but the finances of the cloud? I've talked to many customers that when you modernize, you pull things apart, maybe you start leveraging serverless capabilities and if I tune things properly, I can have a much more affordable solution versus if I just took my stuff and just shoved it all in the cloud, kind of a traditional lift and shift, I might not have good economics when I get to the cloud. What do you see along those lines? I'd say you're absolutely right with that assessment. If you are looking at hitting break even on your cloud migration in anything less than five years, it's probably wrong. The reason to go to cloud is not to save money. There are edge cases where it makes sense, sure, but by and large, you're going to wind up spending longer in the in-between state than you would believe. Eventually you're going to give up and call it hybrid or game over and at some point, if you stall long enough, you'll find that the cloud talent starts leaching out of your company to which point that, okay, great, now we're stuck in this scenario because no one wants to come in and finish the job because it was harder than we thought we planned it. But it becomes this story of not being able to forecast what the economics are going to look like in advance, largely because people don't understand where their workloads start and stop, what the failure modes look like and how that's going to manifest itself in a cloud-providered environment. That's why lift and shift is popular. People hate lift and shift. It's a terrible direction to go in. Yeah, so are all the directions you can go in as far as migrating, short of burning it to the ground for insurance money and starting over? You've got to have a way to get from where you are to where you're going. Otherwise, cloud migrations would be super simple. People with five weeks of experience and a certification can solve that problem. It's, but how do you take what's existing, migrated in without causing massive outages or cost overruns? It's harder than it looks. Well, I remember Corey, a few years ago, when I talked to customers that were using AWS, a common complaint was we had to dedicate an engineer just to look at the finances of what's happening. One of the early episodes I did of Cloud Native Insights talked to a company that was embracing this term called FinOps. We have the finance team and the engineering team, not just looking back at the last quarter, but planning, understanding what the engineering impacts were going forward so that the developers, while they don't need to have all the spreadsheets and everything else, they understand what they architect and what the impact will be on the finance side. What are you hearing from your customers out there? What guidance do you give from an organizational standpoint as to how they make sure that their bill doesn't get ridiculous? Well, the term FinOps is a bit of a red herring in there because people immediately equate it back to cloudability before their AppDeo acquisition is, oh, where the FinOps Foundation vendors are not allowed to join except us. And it became effectively a marketing exercise that was incredibly poorly executed and sort of poisoned the well. Now that the FinOps Foundation has been handed off to the Cloud Native Computing Foundation slash Linux Foundation, maybe that's going to be rehabilitated but we'll have to find out. One argument I made for a while was that developers do not need to know what the economic model in the cloud is going to be as a general rule. I would stand by that. Now someone at your company needs to be able to have those conversations of understanding the ins and outs of various cost models. At some point you hit a point of the deep complexity where bringing in experts to solve specific problems begins to make sense. But every developer you have does not need to sit through a three to five day course understanding the economics of the cloud. Most of what they need to know fits on a business card. Fits on an index card or something small that is cart-like and can solve business and other index problems. But the point is, it's great. Big things cost more than small things. You're not charged for what you use. You're charged for what you forget to turn off and being able to predict your usage model in advance is important and save money. Data transfer is weird. There are a bunch of edge cases, a little slice of the ribbons, but inbound data transfer is generally free, outbound generally costs an arm and a leg and architect accordingly. But by and large for most development product teams, it's build something and see if it works first. We can always come back later and optimize costs as you wind up maturing the product offering. Yeah, Corey, it's some of those sharp edges I've loved learning about in your newsletter or some of your online activities there, such as you talked about those egress fees. I know you've got a nice diagram that helps explain if you do this, it costs you a lot of money. If you do this, it's gonna cost you a lot less money. Even something like serverless is something that in general looks like it should be relatively inexpensive, but if you do something wrong, it could all of a sudden cost you a lot of money. Do you feel that companies are having a better understanding so that they don't just one month say, oh my God, the CFO called us up because it was a big mistake? Or where are we along that maturation of cloud being a little bit more predictable? Fortunately, nowhere near where I'd like us to be. The story that I think it's missed is that when your month over month spend is 20% higher, finance has a bunch of questions, but if it were somehow 20% lower, they'd have those same questions. They're trying to build up predictive models that align. They're not saying you're spending too much money, although by the time it finishes the game of corporate telephone, that's what people are going to hear. It's instead help us understand and predict what's happening. Now, serverless is a great story around that because you can tie charges back to individual transactions. And that's great, except find me a company that's doing that where the resulting bill isn't hilariously inconsequential. A Cloud Guru before they bought Linux Academy would get on stage and talk about this at serverless company for a year, but how they're spending $600 a month in Lambda and they have now what, well over 100 employees. Yeah, no one cares about that money. You can trace the flow of capital all you want but it rounds up to no one cares. At some point that changes, but there's usually going to be far bigger fish to fry. With their case, I would imagine, given they stream video, they're probably going to have some data transfer questions that come into play long before we talk about their compute. Yeah, what else Corey, when you look at the innovation in the cloud, are there things that, common patterns that you see that customers are missing some of the opportunities there? How do the customers that you talk to, other than reading your newsletter, talking to their systems integrator or partner, how are they doing it, keeping up with just the massive amount of change that happens out there? Forget customers, AWS employees follow the newsletters specifically to figure out what's going on. We've long since passed a Rubicon where I can talk incredibly convincingly about services that don't really exist and Amazon employees won't call me out on the joke that I've worked in there because who in the world could ever say that convincingly? It's well beyond any one person's ability to keep it all in their head. So what we're increasingly seeing, even one provider, let alone the rest, where events are outpacing them and no one is keeping up. And now there's the persistent, never growing worry that there's something that just came out that could absolutely change your business for the better and you'll never know about it because you're too busy trying to keep up with all the other numbers. Every release a cloud provider does is important to someone but none of it's important to everyone. Yeah, Corey, that's such a good point. When you've been using tools where you understand a certain way of doing things, how do you know that there's not a much better way of doing it? So I guess the question is, there's so much out there. How do people make sure that they're not getting left behind or keep their understanding of what might be able to be used? The right answer there, frankly, is to pick a direction and go in it. You can wind up with analysis paralysis issues very easily and if you talk about what you've done on the internet, the number one response you're going to get immediately is someone suggesting an alternate approach you could have taken on day one. There is no one path forward for any of these things and you can second guess yourself that. The problem is that you have to pick a direction and go in it. Make sure it makes sense, make sure it aligns, talk to people who know what's going on in the space and validate it out, but you're going to come up with a plan ultimately. Great, head in that direction. I assure you, you are probably not the only person doing it unless you're using Rock53 as a database for some reason. Yeah, no, it's an interesting thing, Corey. It used to be said that the best time to start a project was a year ago, but you can't turn back time, so you should start it now. I've been saying for the last few years the best time to start something would be a year from now so that you can take advantage of the latest things, but you can't wait a year so you need to start now. So, how do you make sure you maintain flexibility but can keep moving project moving forward? I think you touched on that with some of the analysis paralysis. Anything else as to just how do you make sure you're actually making the right bets and not going down some odd tangent that ends up being a dead end? In my experience, the biggest problem people have with getting there is that they don't stop first to figure out, all right, I hear from now, if this project has succeeded or failed, how will we know? They wind up building these things and keeping them in place forever, despite the fact that they cost more money to run than they bring in, in many cases. It's figure out what success looks like, figure out what failure looks like, and if it isn't working, cut it. Otherwise, you're going to wind up wedded to this thing that you've got to support in perpetuity. I mean, one example of that, one extreme, is AWS. They famously never turn anything off. Google, near there to the spectrum, turns things off as a core competency. Most folks wind up somewhere in the middle, but understand that right now, between the day I start building this today and the time that this winds up working down the road, well, great, there's a lot that needs to happen to make sure this is a viable business, and none of that is going to come down to, did I build it on top of Kubernetes or not? It's going to come down to, is it solving a problem for your customers? Are people going to be willing to pay for the enhancement of this? Anytime you say yes to that project, you're saying no to a bunch of others. Opportunity cost is a huge thing. Yeah, such an important point, Corey. It's so fundamental when you look at what cloud should enable is I should be able to try more things. I should be able to fail fast, and I shouldn't have to think about some cost nearly as much as I would in the past. Corey, I want to give you the final word as you look out in the cloud. Any practices, guidelines you can give practitioners out there as to make sure that they are taking advantage of the innovation that's available out there and being able to move their company just a little bit faster. Sure, by and large for the practitioners out there, if you're rolling something out that you do not understand, that's usually a red flag. That's been my problem to be blunt with Kubernetes or an awful lot of the use cases that people effectively shove it into. What are you doing? What is the business problem you're trying to solve? And do you understand all of its different ways that it can fail and the ways it will help you succeed? In many cases, it is stupendous overkill for the scale of problem most people are throwing at. It is not a multi-cloud answer. It is not the way that everyone is going to be doing it or they'll make fun of you and your resume for it. And remember, you have to assume your own ego in this sense. You need to deliver an outcome. You don't need to improve your own resume at the expense of your employer's business. One would hope. Well, Corey, always a pleasure catching up with you. Thanks so much for joining me on the Cloud Native Insights. Thank you, Stu. All right, be sure to check out siliconangle.com. If you click under Cloud, there's a whole second for Cloud Native Insights. I'm your host Stu Miniman, and I look forward to hearing more from you and your Cloud Native Insights.