Cloud Economist Corey Quinn

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

Hey, Keith Townsend, I'm on the road. You see the Airstream in the background, but this is not a CTO Advisor road show or road trip interview. This is actually just a traditional Skype slash Zoom phone call with our good friend Corey Quinn from, I want to say screaming in the cloud fame, Corey, because I saw a kid this morning at the camp that we're at, and he literally had the Corey Quinn look on his face as he was running by. Like three of them all, and in a way, just the Corey Quinn scream, I'm like, kid, you're right on brand.

Corey, welcome to the show. Thank you. It is always a pleasure to talk to you, Keith. I hope you know that by now. You know what? I don't think we've officially done content together. We've talked quite a bit, but I don't think we've actually published anything. It's long past time. Hopefully, we'll eventually hit publish on this until I go sufficiently far off script that it's better that we bury it in the middle of the desert and warn people to avoid the 20 mile radius around it.

All right, so we're not above clickbait, and we're not above talking about the hottest thing or the most interesting thing in tech right now, which has kind of been this Sarah Wang, and I don't know if it's Sarah Wang or Sarah Wong. I might get in trouble if I don't get that right, Sarah Wang and Martine Casado. I have learned how to pronounce Martine's name correctly because earlier in my career as an analyst, I wrote this scathing review of his baby, which went on to become NSX, and I just happened to be in Silicon Valley at the time, and he invited me out for a burrito, and then over a burrito, Martine proceeded to kind of dismantle my whole argument and pretty much put me in my place, but he did pay for the burrito, so.

We take what we can get. I mean, I would never deign to imagine a world in which I tried to explain networking to the guy that basically invented SDN, but now he's stepping a bit into my world of cloud economics. I mean, the Screaming in the Cloud podcast is great and all, please don't think otherwise, and of course, making a scene out of myself on Twitter in the last week in AWS newsletter is great, but I am first and foremost the chief cloud economist at the Duck Bill Group.

I fix horrifying AWS bills for very large companies, and this is a problem in the space I've been thinking about fairly deeply for four years and change now. And with that, let's jump right into it. Me and you have talked about workload repatriation, which wasn't the center of their conversation. They touched on workload repatriation, but I commented, this is maybe about a year, year and a half ago, we talked about it, how I had seen some workload repatriation. People aren't going to call it that, they're not going to advertise it, but I've seen it in the background.

Now, I think this is the perfect time to just talk amongst kind of like two normal folks. You know, we're not from A16Z, we don't have the power of billions of dollars of investment behind us. We're just two small business entrepreneurs trying to make sense of this whole cloud world. I'll just open up the discussion. What have you seen, not just workload repatriation, but as enterprises start to truly figure out, or maybe not, and embrace cloud, what have you seen in your practice?

I think that there's a disconnect in some respects between how different companies view cloud. It speaks on some level to aspects of the now thoroughly debunked Gartner bimodal IT distribution. The problem is, is that some companies view cloud in the sense of, oh, this is part of the good or service that we are selling. It empowers what we sell. An example of this, well, we're having a Zoom conversation, Zoom would be a terrific example of that, where the cloud services empower the video conferencing discussion that we're able to have.

Whereas on the other side of the world, in the, shall we say, the more big E enterprise style companies very often, what they sell is a little bit more prosaic. Think of large blue chip manufacturing companies, where they ship boxes full of things somewhere. And invariably, a lot of the way that they approach all of their spend in cloud and IT across the board is through the lens of purely being a cost center, rather than a contributor to anything that is higher level or differentiated.

If you'll forgive the dramatic oversimplification on this, think these are the people that need to run the SharePoint server over in the corner. I know, I know, most folks aren't doing that anymore, but that's the general ethos and general direction. And in that world, cost counts for an awful lot. I don't see a whole lot of my client base playing in those waters, by and large, because at that point, it's a pure cut-the-cost story. And that's where things like repatriation start to make an awful lot of sense, when it is a pure model of unit economics and you've already, in many cases, made significant capital expenditure investments in data centers.

Whereas when you're looking at shipping something that is a digital product, where the cloud services form an integral part of what you're presenting to customers, the cost always takes a secondary backseat to the idea of feature velocity, of being able to ship new features sooner, improve your time to market. Because unless you're a company in decline, you're focused on growth, and you will wind up being able to make far more than the theoretical 100% of your IT spend that you could cut as a cap, if you launch the right feature to the right market soon enough.

So I don't disagree with your assessment at all, especially from your lens. My lens is from that more traditional IT perspective. My customers are still running SAP on-premises. They're trying to service the growing parts of the business that are out in the public cloud. So I talk a lot about hybrid. How do you make this boat anchor of a SAP or HP UX integrate with services in AWS, so Lambda, et cetera? So I'm not on the bleeding edge of cloud technologies as an enablement for my core audience, but my core audience needs to understand how these things interoperate and the tensions behind it.

The bimodal IT thing, I agree, was a bad idea. It didn't work. At the end of the day, especially in the big E enterprises, as you described it, they have to just do all of it, and it's just another thing that they manage. But I think you're in a unique position to answer a question that's been gnawing at me since this report hit, which was cloud proper, the way that AWS has delivered cloud has been around for about 10 years. That's enough time to have built up technical debt.

And as you work with some of your earliest customers now today versus then, what's the change? What's the delta? What's changed over the years for them? It varies based upon customer. Three reference customers that were named in a news article, and they haven't objected to their name being dropped, and we do have logo rights, are the Washington Post, Epic Games, and Ticketmaster. All three of those companies predate the era of modern cloud. In fact, most large cloud installations do, if for no other reason than it takes time to build up hundreds of millions of dollars a year in spend, and without having been doing it for a little while.

It's very rare to spend that kind of money in the first two years a company's been in business. So there's always technical debt. I have technical debt from things I wrote six months ago. I look at things, and what fool wrote this, and get blamed, says it's me. So then we need never speak about that ever again. But there's a constant story of continuing to evolve. The Washington Post is a great classical example where originally they were a print newspaper.

Still are in many respects, but my subscription is purely digital because I don't have a parakeet. I don't need a physical piece of paper showing up every day that I can then wind up spilling coffee on. I want the content, but I don't need the physical delivery infrastructure, and they, like every other major print publication, have a plan that winds up working for me in that respect. Journalism has changed. All these industries have changed, and legacy is often a condescending term that engineers use to mean it makes money.

When it's revenue-bearing, great. There's nothing inherently wrong with the way that things were built. This idea coming out of Silicon Valley that anything that is more than 18 months old, that doesn't work, it isn't designed to run on the latest version of Chrome, on the current generation Apple MacBook Pro, is somehow a failure. I think that is one of the more toxic attitudes to come out of our entire ecosystem. Funny enough, I talked to a small manufacturing company the first week of the CTO Advisor Road Trip.

The guy had equipment in production that was 50 years old. Then he showed me this super slick laser cutting machine that was a few weeks old that was a half a million dollars. The way that he looked at technology was very refreshing and eye-opening. One of my first impressions was going into the office space and the graphics artist that takes the requirements from the customer and then creates a layout, et cetera, et cetera, their printing organization. He had a cheese grater Mac.

I'm not talking about the new cheese grater Mac. He had the old cheese grater Mac from 2007, 2008 on his desktop. I thought, wow, this business owner looks at the cheese grater Mac the same way that he looked at the 50-year-old piece of equipment and the three-week-old piece of equipment. Does it do the job and will it earn me money? Sure, I can upgrade the guy to the latest and greatest widget, but what does that mean? I love to use this forklift scenario because I think we intuitively understand the value of new forklifts.

He could literally look at, I could literally look at the old forklift on his platform and think, wow, he has to make the decision on whether or not to buy a new forklift or upgrade his graphics artist to the latest version of Mac and Mac OS, et cetera. At the end of the day, does it make him money or does it reduce risk or does it save him money? When you're in a manufacturing company, it's not like working in a software company. As you look out across your manufacturing floor that is, what, $100 million worth of equipment sitting on it, and you look at the $10 million a year in payroll, you're paying people to work on these things, and then you look at your, what, $2 million a year in cloud spend, it sort of disappears in a way that it doesn't in a software company.

You take a company like Zoom, for example, that is streaming video all over the planet all the time. Yeah, a meaningful reduction on a percentage basis of their IT spend is massive for them, but in the context of the manufacturing floor, it's one of those, yeah, I could spend all that time and effort reducing my cloud bill, or I could buy another one of those $5 million pieces of equipment and actually speed up my ability to increase my throughput, increase my ability to ship things faster, sooner, and bid for larger contracts.

It's the same type of approach, and I think that on some level, one of the most valuable services I tend to provide to my customers has been telling them when to stop cutting. It's, yeah, you can keep throwing engineering effort at reducing this bill, but past a certain point, it's not going to add any business value. You're stepping over dollars to pick up pennies. So with that, I would love to end on kind of this concept of what's real. I think me and you, whenever we get together, we get to talk about what's real, what's real from my lens, what's real from your lens.

You're coming at it from typically the type of organization that Sarah and Martine wrote about in their report. They're a software company. They're making money from software, and software is part of their cost of goods, and cloud is part of their cost of goods, rather. And then I'm coming from a more traditional sense, and I think there's a sense of it meeting in the middle a little bit, at least it's starting to, as enterprise companies are adopting cloud that was built in departments other than centralized IT, and they're kind of waking up to, from one, a cost perspective, and two, a governance perspective.

This is where I see it. So I'm not seeing, you know, I don't work with the CMO to build a new cloud app. I work with the VP of IT infrastructure after the CMO has thrown it over the window to them to maintain it because they've gotten the initial value. Where are you, in your practice, seeing the collision of big enterprise E and cloud and cost or innovation? Sure, we can even take the Dropbox example because that is the most well-known story of cloud repatriation, and I don't think that that was a foolish decision either.

I think at the time, they had one very well-understood, very large workload storing user files that at the time, S3's economic model didn't lend itself to horribly well. They were looking at what they could do with all these engineers because they were sort of out of ideas at that point. They'd hit product market fit as a folder that syncs everywhere. And what they hadn't quite figured out yet is what else can we do? Frankly, if they hadn't done the cloud migration, we would have had that horrible Dropbox app and all the collaboration services no one wants inflicted on us years sooner.

So there is that. But in their S1, where they talk about this, about how they reduce their operating expense and cost of goods sold by something like, was it $75 million over a two-year span? Look at that same two-year span. They had an effective $200 million charge in CapEx, which does not flow through to COGS. It's partly accounting trickery, not trickeries if they're doing something disingenuous, but which pocket it comes out of at the large enterprise scale matters to how a company is perceived in the market, at least in theory.

In practice, it seems that the market is so far divorced from fundamentals that whether a company is doing well or not is almost beside the point. You can look at companies that there's starting to be emerging analyst consensus where their valuation is larger than their total addressable market. How's that going to work exactly? It's we're in something of the wild times. We are in something of the wild times. And as a cloud economist and as a former PWC guy, I can't help but look at these things and think about and make the connection.

What does that mean for the guy in the trenches? Like the guy that needs to make technical architectural decisions? How does the financial implications of the market impact their day-to-day? And I'll leave that question to you to kind of end us off on. Why should the cloud architect care beyond their stock options, care about the evaluation or the market's view of their organization? The honest real answer is because their boss does. And they are the tool with which the corporate strategy is being carried out.

And when something matters to a company, ideally, that winds up echoing down throughout the rest of the organization. We saw some negative impacts of this until somewhat recently, where companies that were used to doing significant amounts of capital expenditure were looking at how they could classify their cloud spend as CapEx instead of OpEx. And there were a bunch of accounting tricks you could do until the auditors caught wind of exactly what they were doing and what the implications were, issued additional guidance on two regulations that govern this.

And now you see a bunch of companies backing away from doing it. It comes down to this idea, historically, of, well, if we shift a bunch of CapEx to OpEx, that'll affect our earnings per share. And that, in turn, is going to basically get us all fired. Yes and no. Take a look at how your competitors are doing it by this point, because I assure you, whatever market you're in, a number of competitors already have, and see how they've weathered those storms.

We haven't seen the dramatic swings in market price based upon what a cloud environment looks like. The only time we start to see it having serious impact for the stock, and even then, it's generally a short-term process, from the architecture view, is when there's a security breach. And then you have this sort of ablative see-saw that burns through and gets replaced, and life goes on. A year goes past, and generally speaking, the company has a higher valuation than they did at the time the breach was discovered.

So ironically, I'm going to visit HPE Financial Services later on this week as part of the road trip. And this absolutely matters. I can't tell you how many times in my career that architecture was dictated by OpEx versus CapEx and not what was the best technical solution. And companies need- We're starting to see those shackles loosen. Starting to see them loosen, and companies need help with that transition. We'll do some content, and maybe me and you will talk about the economics of moving from an OpEx to a CapEx model, or a CapEx to OpEx model.

It is surprisingly difficult, because architecturally, there has to be a tipping point where you're spending less in one bucket and more in another. And overall, IT spend, you're spending more in the middle and during that transition, and how to accommodate that architecturally. So for my audience, who just simply, they've gotten this bill thrown over to them, and now it's part of their expense thing, and they don't know anything about public cloud. Welcome to the club. How do they get a hold of the Duck Bill Group?

com is probably the easiest way to find us. And the fun thing that we've noticed is that despite whoever it is that we talk to, and wherever they fall on whatever maturity curve you'd like to put them on, no one takes a step back and says, oh, yeah, we've got a great handle on our cloud spend, or even all of our IT spend as a whole. Everyone always asks, well, how are the people who are good at this handling this? And you talk to the people who are legitimately ahead of the curve, and they have the exact same perspective and the exact same questions.

Well, it feels like we're not quite doing this right. That's normal. As the old line goes, there's a support group for that. It's called everyone, and we meet at the bar. It's the, this is a very common story. It's a very common occurrence. No one really feels that they have this stuff on lock yet, but practices continue to emerge around this and how to do these things. It's easy to forget that given that despite the fact that cloud is 10, maybe 15 years old, if you're, depending on how you want to view it, great.

It's still new, there's still new times. It's not exactly clear how these things work, and it's definitely evolving a lot faster than the on-premises world did. All right, so if you want to learn more about Corey in general, like, subscribe to his newsletter. It's legit something that I tried to do, and I just, I don't know. He says it's simple, but it's high quality, one of the most high-quality newsletters you can find in this space, wealth of information. com, at CTO Advisor's Twitter handle.

DMs opened. I do not have the ability to help you and your family of five find housing. Not really my cup of expertise and my essential expertise, but if you have questions about enterprise IT, DMs are open. Talk to you next, CTO Dose.