Screaming in the Cloud - The Law of Cloud Entropy with Owen Rogers

Episode Date: June 1, 2021

About OwenOwen Rogers wears many hats at 451 Research; he’s research director of cloud transformation and digital economics and head of the quantum computing centre of excellence. Prior to these positions, Owen was a doctoral researcher in cloud computing at the University of Bristol, completing his PhD thesis in 2013; a product portfolio manager at Claranet; and an independent product management and cloud computing consultant, among other positions.Join Corey and Owen as they talk about what it’s like when two cloud economists meet at an event but only one has a PhD, what exactly an industry analyst does, how 451 Research found that 53% of companies increased cloud spend during the pandemic and what resources they’re investing in, the Law of Cloud Entropy and why Owen believes the cloud will only get more disordered in the future, why it’s easy for cloud costs to spiral out of control, how organizations are trying to rein in cloud spend despite using more cloud services, why Owen doesn’t believe we’ll reach cloud commoditization anytime soon, and more.Links:451 Research: https://451research.com/Cloud Price Index: https://451research.com/services/price-indexing-benchmarking/cloud-price-indexTwitter: https://twitter.com/owenrog

Hello, and welcome to Screaming in the Cloud, with your host, Chief Cloud Economist at the Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud. This episode is sponsored in part by Thinkst. This is going to take a minute to explain, so bear with me.

I linked against an early version of their tool, CanaryTokens.org, in the very early days of my newsletter. And what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing, in various parts of your environment, wherever you want to. It gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It's an awesome approach. I've used something similar for years. Check them out. But wait, there's more. They also have an enterprise option that you should be very much aware of. Canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your

entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets NMAP scanned, or someone attempts to log into it or access files on it, you get instant alerts. It's awesome. If you don't do something like this, you're likely to find out that you've gotten breached the hard way. Take a look at this. It's one of those few things that I look at and say, wow, that is an amazing idea. I love it. That's canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I'm a big fan of this. More from them in the coming weeks. This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the enterprise, not the starship. On-prem security doesn't translate well to cloud or multi-cloud environments,

and that's not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35% faster, and helps you act immediately. Ask for a free trial of Detection and Response for AWS today at extrahop.com slash trial. Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Owen Rogers, who's a Research Director of Cloud and Managed Services Transformation at 451 Research, a part of S&P Global Market

Intelligence. Owen, thank you for tolerating my slings and arrows. Lovely to be here, and I look forward to them. So you got your PhD back in 2013 in cloud economics. And I know this because when we first met at a cloud economics event, I called myself a cloud economist, and you lit up like a Christmas tree. Oh my God, someone else does what I do. And I just gave myself the title because I thought it was something I'd invented, whereas you actually got a PhD in it. And you made the understandable assumption that I knew what I was talking about. And I knew I had two directions I could go in.

The first was to be honest and come clean. And the other was to basically string you along until we co-publish a book. It comes out in two weeks and its title is, I'm kidding, I'm kidding. But thank you for being as gracious about me stomping on your credentials back then as you were. No, I was relieved actually that someone else was looking into this because I thought I was just on my own. And I made this big gamble by coming up with this PhD and taking a bit of a risk. And when I saw you at that event, I was like, thank God it's not just me. Thank God this

actually might be a thing to pay attention to. So thanks for being there. No, by all means. It turns out that there's a very narrow subset of people who care about these things. And that tends to be a somewhat insular circle. So it was nice to finally meet someone who was a bit outside of the nuts and bolts of lowering bills and looking at the broader implications across the market. But we'll get there. You're an industry analyst. What does that mean? So essentially, we are the intermediary party between buyers and sellers. So we help sellers of services and goods work out who to sell to, how to sell, and we help buyers work out what product's best for them. And we do this by

conducting market research across buyers and sellers pretty much. So my specialism is cloud economics. So it's my job to help solve a lot of this complexity that's going on in cloud pricing for enterprises and to help service providers and tech vendors sell and price appropriately? Well, let's define terms as well. One of the hardest ones is cloud. In fact, the reason I called myself a cloud economist is because it was two words that no one could accurately define in almost any context. Cloud generally meant a bunch of people's computers that weren't yours. An economist generally meant someone who claimed to know everything about money but dressed like a disaster victim and put the two together and no idea what the hell I did. And in many cases, they still don't, which is kind of ideal from my perspective. But when you say

cloud, what does that mean? Are we talking infrastructure as a service? Are we moving up the stack into SaaS? Are we taking a Microsoftian definition and including LinkedIn revenue as part of their cloud unit for some godforsaken reason? What is it? Where do you start? Where do you stop? I mean, when we both started looking at cloud economics, it was all about the infrastructure because people wanted virtual machines and storage. And there's a huge amount of complexity there. But I think as the market has become more mature, increasingly we're seeing people want to use all these other services up to the platform level and the software level. So I'm interested primarily in infrastructure and platform. But the thing about cloud providers nowadays is there doesn't

seem to be any barriers to where they want to go. And I think you and I and others who are in this field are going to have to broaden our horizons and start thinking about everything, because cloud is becoming the center of all IT, really. What I find strange is that as the further I go afield from my core competency in this space, which is looking at the AWS side, infrastructure as a service spend, which is not small in most companies

and not getting any smaller, as soon as you start diverging from there, the requests that I start seeing from customers are all over the map. Some of them are trying to work on their Microsoft licensing. Others are trying to optimize some random SaaS tools billing because that's top of mind at some point. It immediately shatters into a thousand different niches. But the common thread that I've always found was the AWS bill. And let me be very clear, that's a function of who I talk to in my market in which I live here in San Francisco. That does not mean that AWS is in every type of company of every profile,

just the ones that I started talking to and figured out that I could help. Yeah, that would make sense to me. I think COVID in particular has made companies realize the cloud is an option. So even though not everybody was using the cloud hyperscalers one or two years ago, I think over the past year, even if you weren't dabbling in the cloud, perhaps you've started to play around. And even though optimization might be the first thing you think of when you start using the cloud, as time goes on and things start getting carried away, then that's when this optimization is going to become more important. So for example, we found 53% of enterprises we surveyed are using more cloud services as a result of the pandemic because they've had to change

things. And even though they've probably spun it up really quickly because they need to grab hold of it quickly and take hold of the opportunity as soon as they could, in years to come, there's going to be so much complexity and they're all going to have different requirements, as you said, because they're all using things in different ways to address their different needs as the pandemic has gone on. Talk to me a little bit about the COVID spike that you're seeing. Is that people spinning up a bunch of new VMs? Is it people leveraging different video conferencing services like Zoom or, God forbid, WebEx? Is it something else entirely?

I think there's two areas, and pretty much what you said. So there's some companies who are scaling their existing cloud resources. So those who have built scalable applications, they're just adding more and more virtual machines or auto-scaling so that they can keep up with demand. And as you said, that could be something like video conferencing, authentication, VDI, anything like that. But then there's also companies who have had to really rapidly change business model

because a year ago, they weren't selling things online. They weren't able to deliver. Everything was bought in a shop. And now they've had to rapidly get access to cloud resources and rebuild their businesses almost. And I think there's lots of new cloud users as a result of the pandemic who thought, how are we going to suddenly get this infrastructure? Well, we're going to have to go to one of the hyperscalers to get used to it, to get hold of it right now. One of the things that caught me by surprise in the early days of the pandemic

was a number of different companies whose business models weren't really extending to online things in the same way. They were all based around real-world physical commerce, for lack of a better term. Saw their user traffic and their e-commerce traffic fall off a cliff, but their infrastructure span remained relatively stable.

At which point we realize, oh, interesting. When everyone talks about being able to auto-scale, they just mean up. And that makes sense on some visceral level, because if you don't scale up, you drop customers on the floor. If you don't scale down, well, it just costs a little bit of extra money, and that's not the end of the world, comparatively. And suddenly seeing people in somewhat dire straits in a company context and having to renegotiate their commits with different providers was something of an eye-opener. entropy and came up with a term called the law of cloud entropy and what that essentially means is cloud is only likely to get more disordered over time because most enterprises as you said would rather just leave things running would rather scale up than risk scaling down because if they scale up it means

their applications can still continue to run they're not going to be shot in the foot by a server going down but if they're scaling down too quickly, then they've got a lot to lose and only a tiny cost saving to make. So it's almost like the cloud model is inherently risky in terms of cost running away with it because things can happen automatically and there's so much to lose by getting it wrong. Absolutely. After your cost saving exercise winds up causing an outage, you're generally not allowed to save money anymore. Yeah, yeah, totally. Like, why risk saving a few cents when it could bring your business down? But that's the thing. I mean, it's not just a few cents anymore, is it? Because over time, people consume more and more resources, things aren't

being managed correctly. It's really easy for those costs to spiral out of control. And then it's not just a few cents. It's thousands, tens of thousands of dollars. And there is a point where you think, well, actually, I am going to have to do this now because costs are spiraling. And it is time to take that step into optimizing and cutting my costs. I've got to level with you. It does not stop at tens of thousands of dollars.

Many of my clients wish it did. Sure, we can eat that, no problem. It becomes something so much deeper, and it grows without any bounds on it. If you spin up an instance with the idea that you'll just experiment on something and then turn it off in a couple of days, if you don't proactively turn it off yourself,

you're going to retire before that instance does. It'll sit there costing you every hour of the day. Well, I've done that, as I'm sure you have. I've spun up a virtual machine, played around, and then six months later, I've been like, oh, this is surprisingly expensive. And then I'm like, oh, well, I'm not going to be able to expense this, am I? It's only going to get worse. So 49% of enterprises we survey say their cost savings are going to be a greater priority since COVID. So ironically, even though people are using more cloud and perhaps these costs are

spiraling out of control a bit, the fact of the matter is they've never been under more pressure to try and quell it. Oh, yeah. And it doesn't get any easier when people look at these things in their own right. And it doesn't lend itself to easy analysis, especially as you start getting into large swings. You have seasonal cycles, you have people buying reserved instances or savings plans or whatever the other provider equivalent is in bulk at certain times of the year. And it's very difficult to do accurate projections, especially when you don't know the answer to a number of very pressing business questions. It almost becomes, in my case, marriage counseling between finance and engineering.

That's such a shrewd observation, because I think there is this huge disjoint between IT and finance. And I can't really see that being solved anytime soon, because they're both at, you know, finance's job is to save money, but IT is to keep things ticking over and to innovate. And unfortunately, it's a compromise. But to get a compromise when neither party really understands each other's field is really tricky. Absolutely. If AWS were to somehow wave a magic wand and fix their billing, and my God, I wish they would, I still have a business here. I still have a credibility when talking to a customer about, is this the right level of spend or right level of commit that you're never going to have when your email address ends in the same domain as the vendors. And the ability to help

them negotiate what those commits look like with that vendor is one of those business models that never goes out of style. Yeah, there's always going to be that negotiation. Although I think it's not as big as it used to be. So when it was like server hardware 20 years ago, you know, the list price was nothing like the price that you'd actually pay. Whereas in cloud, I think, I don't know if you agree, but the variation seems far smaller to me. It almost seems 10 to 15% rather than the 50 to 60% it might have been 20 years ago.

At certain points of scale, that no longer holds true. Interesting. Interesting. Not to name names or specify numbers. Again, confidentiality matters. But at some point, when you wind up being a significant portion of a given service's revenue, again, no one is paying retail or anything even close to retail at a certain point. And things are only going to get more complicated. So we track all the things for sale from AWS, Google, Microsoft. And every week we scan out 2 million individual line items for sale from those cloud providers. So even if there was some kind of standardization,

list price was everything, that's not going to apply to all of those different line items. So I think for people like Duckbill, a lot of the need is to look at this whole bill, look at everything that's being used for opportunities to optimize and negotiate, not just on the handful of services which most enterprises are using. When you say that you can consume all of those pieces of information in a single week, that tells me you're doing some definite data crunching and big number processing, largely because it's impossible to get that much clarity within a week. Do you find that the cloud providers themselves change pricing other than on things like preemptible instances or the spot market

without an announcement? Interesting. So the cloud price index, which I manage, we essentially every week, we look at the websites of all these cloud providers, we go through their APIs, and we look at every price item they have, and we compare it to the week before. And sometimes prices just go up and down, just like a blip. It's almost something's gone wrong on the website or the API. But in 2020, we saw 4,000 significant price cuts. So a significant price cut is one that is greater than 10%. So sometimes prices go down over time, and the cloud providers don't make a big song and dance about it anymore. But other times, prices do go up.

And those prices seem to go up in particular when a product goes from almost a beta into general availability. And different cloud providers do it in different ways. But yeah, I think prices are almost continually changing. And it's almost like a sea of prices rather than thinking, oh, well, everything's going down or some things are going up. Things are going up and down all the time. And it's tricky to really know what's going on. I think this is why cost optimization is going to be needed on an ongoing basis, because it's not just a one-off thing anymore where you go and buy a bunch of reserved instances.

You need to be constantly reassessing this all the time. And like we were talking about the synergy between IT and finance, you need to work out what the company is going to be doing in a year's time so you know if it's worthwhile investing in something to make those savings. When you say that there are thousands of price changes, generally decreases, are they often correlated? In other words, if we're going to be reducing the cost of the X instance family, the end. But then there's thousands of SKUs on some cases because they're in all of the different regions,

they have all the different pricing for the committed price, the reserve price, et cetera, et cetera. Or are they making large-scale cuts and just not mentioning it? Because there was a time on the AWS side, which is where I live, where they would trumpet every minor cost reduction in some far-flung region for some service that basically no one used.

You're right. A lot of those cuts are because of a family or a particular region or a generation. And obviously, one cut translates to thousands of individual line items, which again shows the complexity for companies to deal with because they've got to understand that one change can affect a whole range of different things. It's not just one change anymore, it's tens of thousands. What I hope is that at some point, we're going to start seeing something approaching commoditization in this space. But the price that has never materially changed, well, that's unfair. The price that has generally never materially changed has been the egress fee for data transfer. See, I don't think we're going to reach

commoditization for a long time yet. And I think of it as a gas station analogy, right? So if there's a bunch of gas stations all on the same road, we all know that the cheapest gas station will be the one that probably gets most of the business because people are only buying gas. But the reality is people go to gas stations for loads of different things. They go because one might have a nice restroom,

one might sell different chocolates and candy. So it's not really about the commoditized offering of the gas. There's loads of other things that would drive why you might choose one gas station over another. And I think that is the same with cloud providers that, yeah, they all might get similar prices for virtual machines at some point. But still, there's going to be a reason why you might choose AWS or Google or Microsoft or Oracle or IBM or Alibaba or any of these folks, it's going to be because of their whole portfolios and everything else they offer and trust and reliability and

regional access and not just that single commodity price point, which is their core business. Part of the problem is, at least in my experience, when I look at the customer profile that I tend to engage with, they have the bulk of their expenses across a very small number of services. Almost always EC2, RDS, S3, Elastic Block Store, and data transfer. And everything else is sort of a bit of a rounding error. There are always going to be exceptions on this. But what that tells me is that despite all the high-level services that get trumpeted, and despite the flashy abilities and capabilities and savings opportunities, etc., etc., that get trotted out during all of the provider keynotes, people are still largely using this to run virtual machines and store data. Is that a fair assessment from what you're seeing? I would strongly agree

with you. And it's because people know how to build applications on servers. There's different skills, but people have got the skills already to some degree. Whereas if you want to use serverless or these new analytics tools or IoT or machine learning, that's a whole new skill set. I'm with you. I think the bulk of it is still the basic infrastructure items. It really seems to be. And I can't shake the feeling that as much as they want to give attention to the new stuff,

it's not a massive driver of people who are debating adopting the cloud. I really don't think that it's going to change anytime soon. If we take a look at AWS that has an annualized $51 billion run rate in revenue at this point, which is just astonishing, it's pretty clear the next $51 billion is not going to come from the same customer profile. If anything, it's going to come from what look an awful lot like blue-chip companies, some of whom are in manufacturing,

some of whom are in logistics, etc., etc. They're not web properties. They're not Netflix-style companies. And to meet those people where they are, they have to embrace the edge a lot more closely. They have to tell a story where you can manage the data center and the cloud environment similarly. And if anything, it's going to increase that trend, not decrease it. How do you feel about multi-cloud, mate? I was hoping we would get there. I have thoughts on the matter, but I will do you the service of letting you start. So 59% of enterprises we talk to are pursuing a hybrid approach to IT.

So what that means in our language is essentially enterprises want to make sure they can use different cloud providers. And the top reason they want to do that is because they want to choose which is the best expertise from each individual cloud provider. So yeah, they might want cloud provider A because they've got really cheap infrastructure, yada, yada, yada. But they still want to have the freedom to use cloud provider B because they've got really cheap infrastructure, yada, yada, yada. But they still want to have the freedom to use Cloud Provider B because they've got these cool, sexy new analytics and stuff. And for me, I think the hyperscalers almost have to have these newer, sexier services. Not necessarily because lots of companies are going to use them and it's going to erode all the commodity business, but more because if they don't have them, it almost appears like a bit of a weakness

because their competitors all have the same thing. And considering enterprises are so willing to consider multiple cloud environments, I think that more appropriately shows that you have to have these things because companies will look elsewhere if you don't. This episode is sponsored in part by our friends at Lumigo. If you've built anything from serverless, you know that if there's one thing that can be said universally about these applications, it's that it turns every outage into a murder mystery. Lumigo helps make sense of all of the various functions that wind up tying together to build applications. It offers one-click distributed tracing so you can effortlessly find and fix issues in your serverless and microservices environment. You've created more problems for yourself? Make one of them go away. To learn more, visit lumigo.io. I'm not going to disagree with what you're saying because I'm not sure of the direction it's going to go in yet.

I've often have been mischaracterized that when I rant about multi-cloud being a worst practice, that I'm saying that you should absolutely pick one provider and go all in, full stop. And that's never been what I intended to say. For example, personally, all my infrastructure lives on AWS,

give or take a few things that are hosted WordPress, for example. But my Git repositories live on GitHub because CodeCommit is a funny joke that people just haven't realized is a joke yet. And I use G Suite for email and the rest because work mail and work docs are services that even now you're not sure I'm not making up. And that's the way that I tend to view the multi-cloud story. Different workloads in different places. And that tends to be fine, because in this case, there's not a whole lot of interaction between those things. The dumb version of multi-cloud to my world,

and I think you called it hybrid in some respects, is the idea of, I'm going to take a workload that can seamlessly go to any different cloud provider at any time. And in practice, it never does that. And it also winds up trading off a lot of the benefit of going to public cloud in the first place. Yeah, that makes sense to me. And actually, in our data, that's exactly what we find. So it's something like the average number of clouds used by an enterprise of WeSurvey is 2.3 on average, but 80% of their workloads are deployed in one cloud.

So I think you're right. It is almost an aspiration. It's just keeping your option open. Having the ability to move workloads between clouds constantly, we don't see it either. It's more about just having the ability to if you really needed to. Do you think some of that is because people are just scared of that lock-in in your experience? Is it more of a psychological worry than actual a worry in reality? Partially that. It's also that there's a vendor ecosystem where if you're selling a shared control plane that can speak to all three of the primary tier one cloud providers and people aren't using multiple cloud providers, you suddenly aren't using multiple cloud providers,

you suddenly have nothing left to sell them. It's also being sold in many respects by cloud providers who are painfully aware that if you go all in on one cloud, it will not be theirs. Yeah, makes sense. But it's been interesting over the past year or so how the hyperscalers have started talking much more about hybrid and multi-cloud, right? So five years ago, I didn't think AWS would ever have something like Outposts. And also their competitors. So Google have Anthos, where you can move workloads. Microsoft come up with Arc. So it's surprising to me that they're all embracing this concept so readily. Well, I do want to call out

that there is a distinct difference in my mind between using multiple cloud providers and having a hybrid structure where you have a data center and a cloud provider. Because everyone goes through a migration process there. In fact, a failed cloud migration is called, we're hybrid now, because it turns out midway through,

it's super hard to move something, so you give up and declare victory. No one generally sets out to live permanently with a foot in each world. What invariably happens then is they improve their data center at the expense of their cloud environment, and they really tend to treat the cloud, more or less, as an incredibly expensive place just to run a bunch of virtual machines, compared to what they would get economically on-prem. Now, that said, the raw infrastructure cost is only a small part of the story. Yeah, because you've got the labor cost of running it yourself as well, right? Which is always more expensive than the infrastructure.

It's an incredible rarity when we see the AWS bill costing more than payroll. Then again, I think, you know, it's not just the cost savings of having some of your cloud stuff on-prem though, is it? I mean, the world is a complex place at the moment, pandemic, politics. I think some buyers like to have their data somewhere where they know in a country they understand the compliance and the sovereignty. I mean, even though cloud is an easily accessible place, you still don't have ownership of it all. There's some things you just want to keep close to home. And that is a lot of the driver we see for the hybrid model. The public cloud gives the flexibility, but the on-prem cloud lets you still have some flexibility, but

keep it all controlled and in your own arms. To be very clear, I'm also speaking in the very general case. When I talk to individual clients who have made a different decision, my default assumption there is that they've thought I absolutely must build everything that I'm doing in the cloud to work on multiple providers on day one. And that's just not the case. I see what you mean. Yes, that's not the case. Just because people are using multiple venues doesn't mean they're all necessarily working together in any sensible way. Exactly. This is part of the reason I have no partnerships with any vendor in this space. It's the reason I don't charge percentages of things. It never goes well. I wind up charging fixed fee to my clients, and then I tell them to do what I would do in their position, and I'll explain my logic as I go, and everyone's generally pretty happy with that. Makes sense. For better or worse, it seems to solve the problem

that folks have. But it's a growing market. I'm never going to be able to talk to more than a very small percentage of it. And this problem has to be solved on some level systemically. Because if we look at cloud spend as an unbounded growth problem, well, first, it means that in the cloud business, it's a great place to be if you're one of the ones that's making money at it. But it also means that at some point, there's going to be some kind of a reckoning where people need to go back and play cloud environment archaeologist. And this isn't just a big company problem. I'm the only person that was in most of our early accounts here at the Duckbill Group. And I have to figure out what that idiot moron known as my past self was thinking when he tried to build some of this

nonsense. And the short answer was, is he had no idea, but it seemed like a good idea at the time. I totally love that Cloud Bill archaeologist, and I will be stealing that for a future reference. And I think you're right. Even during the pandemic, I bet loads of people have scaled up straight away thinking, well, we've got to capture the opportunity now

while we're going to risk losing business. And no one's really planned it or looked at it for a year because quite understandably, they've had bigger things to worry about. And in five years time, no one's going to know what's going on, what workload is tied to what specific application, who owns it. And the thought of even understanding it is challenging, let alone trying to optimize it. And I was having a debate with my colleague, Gina Telsek today, and she was asking me if I thought one day this could all be automated away. And I don't think it can be automated away because there still needs to be someone who understands the business to understand scaling,

to understand if something's worth an investment, to understand if you should scale up or down in response to a specific demand or project. So I always think there's going to be some kind of human intervention, just because humans will understand the needs of the business and relate them to how the cloud has to change. The only other approaches I see in my own are, oh, we're going to build some tools that'll solve all of this for you. And they just don't work. That's terrific to wind up finding specific things, absolutely, but there's no context to them. There's no idea of, should I optimize for this cluster for the long haul, or should I instead wind up focusing on it as this thing that I should immediately ignore? As soon as you start getting three or four terrible recommendations in a row, you wind up in a space of not trusting the tool at all. Bad recommendations are worse than no recommendations. So why do you think that is? Why do you think the tools... I suppose the tools can't predict the future, so they don't know the context of what needs to be

done. Are there any other reasons you see those tools as not being able to adapt? Why do you not think tools will have a longer-term impact? Because in many cases, there's no way to tell from a programmatic perspective. Those idle instances that are sitting there, I'm going to recommend that they get turned off. Well, a little more digging shows that they're the DR site, and you need three seconds of warning or so before they're going to be under load. You can't turn them off. Whereas, buy a bunch of reserved instances on that particular cluster that someone just spun up for a one-week experiment, and then they're turning it off, doesn't make a bunch of reserved instances on that particular cluster that someone just spun up

for a one-week experiment and then they're turning it off doesn't make a lot of sense either. And as you step down this path, it becomes nuanced. There are times where that is a tiny little test environment, so no one's going to look at it or care, except that that tiny little test environment is about to go hyperscale once the business deal gets signed, so now is absolutely the time to optimize stuff like that. There's the idea of, well, this data could be migrated to infrequent access, one zone, and it winds up costing less money. Cool, that's true.

But if that data goes away, it winds up effectively destroying aspects of the business. So in that case, you should spend more money on backing that data up securely, in many cases, to another cloud provider. That's the level of nuance. There's a whole bunch of different things that a naive approach would suggest would be a good idea, but a deeper dive into what the business is actually doing and the model that they're working under make it the wrong direction to go. I strongly agree.

And it gets worse than that because there's this false narrative that companies care tremendously about saving money on the bill. That's the thing that drives them. And it is just not true because it's an inversion of monetary philosophy that people take on a personal level.

If I offer you the opportunity, you can either make another $1,000 or save $1,000, you're typically going to say you'd rather save the money because, well, you can cut Netflix out, you can stop eating out, and that works out well, whereas having to go ahead and make more money, that means you have to ask your boss for a raise and start doing odd jobs and update your resume,

and it's just a pain. Companies, on the other hand, are structured to drive revenue. There's a theoretical just a pain. Companies, on the other hand, are structured to drive revenue. There's a theoretical cap of whatever they're spending on cloud in total that they'll ever be able to cut off, but they can make multiples of that by launching the right feature to the right market at the right time. I wonder if cost optimization is perhaps the wrong word, and it should be something along the lines of value optimization. Because obviously, I don't want any company reducing their virtual machines to save money, because as you said, it's going to reduce their opportunities to gain new revenue if it's their web applications.

Really, it's about, well, this is where you should be putting your money and this is where you're wasting it. It's about optimizing their value, not saving them their costs. Precisely. It comes down to what's right for them, given the constraints that they're working under. And again, it's easy to go ahead and play more or less Wild West architecture, where you look at what they're doing and say, oh yeah, this is all wrong. You should be doing it in this way. And you sketch out a beautiful architecture on a whiteboard, also known as a lie. And yeah, in theory, it's great. In practice, they have existing business, it's driving revenue,

and you're not going to be allowed to turn everything off for 18 months while you rebuild it. The money that you save doesn't matter if you're not in business by the time you're in a position to realize those savings. And perhaps after COVID,

there will be loads of these servers and virtual machines and objects on object storage, which are left there just because it's not really worth removing them because nobody knows what they are. servers and virtual machines and objects on object storage, which are left there, just because it's not really worth removing them because nobody knows what they are. It might bring down the whole business. Better just to leave them there for the time being. Well, that does bring up the last topic I wanted to bounce off of you.

What is the outcome of all of this COVID stuff once it is all passed? What is the lasting after effect, if any, of COVID on cloud? I think COVID will be a catalyst for cloud adoption. Some companies have changed their business models. They've aged collaboration. They've been able to change their businesses in a matter of weeks.

And that's been enabled because of the rapid scalability of cloud, because they've been able to get a third party to do physical server management, and because they've been able to concentrate on changing and evolving their businesses instead of worrying about infrastructure. And I think those who have succeeded by doing that are likely to keep doing that because it's put them in good stead during the past challenging eight months.

And those who hadn't done that will now think, well, perhaps we should have done that. And again, they'll look at the cloud as a way of moving forward. So COVID, although horrifically terrible for so many people, will probably be a catalyst for cloud adoption. And as demonstrated to the industry, the cloud is a suitable venue for many, many workloads. Owen, thank you so much for taking the time to speak with me and suffer my i guess less educated slash informed opinions on cloud economics if people want to hear more about what you have to say where can they find you so you can find me on 451research.com or on twitter i'm owen roge and we will of course put links to that in the show notes thank you so much for taking the time to speak with me i really appreciate it no thank you very much ow taking the time to speak with me. I really appreciate it. No, thank you very much.

Owen Rogers, Research Director and Cloud Economist at 451, Division of S&P Global. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice. Whereas if you've hated this podcast, please leave a five-star review

on your podcast platform of choice, along with a comment listing all 4,000 prices that changed. Whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with a comment listing all 4,000 prices that changed. If your AWS bill keeps rising and your blood pressure is doing the same, then you need the Duck Bill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duck Bill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started. this has been a humble pod production

stay humble