The Many Other High Costs Cloud Users Pay

Isn’t it funny how the same hyperscalers who are maniacal about building everything themselves – and who are making a fortune selling access to their infrastructure as cloud services – want you to use their Seriously Hard Information Technology and stop using your own?

Don’t you find this just a little bit suspicious? We do, and we always have. But when we read a recent post by the folks at venture capitalists Andreesen Horowitz – two people who literally made the cloud way ahead of Amazon Web Services and showed them the way.

Marc Andreesen, of course, is the creator of the Mosaic Web browser that made the Internet so easy that even normal people – well, is anyone really normal? – could use it, and from that sprang Netscape, the first big middleware supplier to commercialize the Internet. Horowitz worked at a bunch of companies, first as an engineer at SGI and then ultimately joining Netscape as a product manager. Netscape was acquired by AOL just as the dot-com boom was peaking in 1998, and the two then co-founded Loudcloud, arguably the first viable public cloud, in 1999. It went public in March 2001, and after some big Global 2000 successes, Horowitz started transforming it from a cloud provider to an infrastructure management tool provider called Opsware. In 2007, a year after AWS launched, and every major IT supplier was completely freaking out about their lack of a cloud story, Horowitz sold Opsware to Hewlett-Packard (the enterprise was a business but not the only one back then) for a whopping $1.6 billion. Now Andreesen and Horowitz could stand toe-to-toe as venture capital with their own bags of dough, and that is what they did.

Suffice it to say, the Andreesen Horowitz team has some deep understanding of the cloud and has built up significant expertise in startups through the things they invest in – and choose not to – since opening up their firm in 2009.

Which is why tongues have been wagging all over the IT world since the venture capitalist firm penned The Cost of Cloud, A Trillion Dollar Paradox. It was not written by either Andreesen (who famously wrote Why Software Is Eating The World back in 2011) or Horowitz, whose book The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers, was written as a guide for aspiring CEOs in 2014. This very good piece of analysis was written by Martin Casado – who works at Andreesen Horowitz after an illustrious career in supercomputing for the US government and creating some of the foundational work in software defined networking (OpenFlow, for instance) that led to the creation of Nicira, which we all know as the VMware NSX virtual networking stack these days – and Sarah Wang, an economist who was an analyst at Morgan Stanley, a consultant at the Boston Consulting Group, and a VC who has been investing in startups for various firms for the past seven years.

Just read it, and here is the link again so you don’t even have to look up. It is an intriguing analysis of how the relatively high cost of using the public cloud is not such a big deal when you are a startup, but bites you in the ass very hard once you have a company that starts to grow and scale fast. We would add that any company moving to the cloud with large and complex workloads gets bitten immediately, and then having gone through all the political, emotional, technical, and professional grief of making the leap find themselves completely stuck, as stuck as they ever were on an IBM mainframe. We have called these big public clouds with their proprietary software stacks “virtual mainframes in the sky,” and we think that pretty much nails it.

Here’s the math that Casado and Wang did. Across 50 of the biggest public software companies that use public cloud services (two different uses of the word public there), they calculate that the exorbitant costs of the public cloud services they use to create – not just run – their businesses actually suppress their collective market capitalization by an incredible $100 billion. If cloud spending were universal in IT, we shudder to think how much impact this would be, but across the “universe of scale public companies” that can benefit from the cost savings of datacenter repatriation, the market capitalization suppression is on the order of $500 billion.

Take that in for a second. Chew on it. Then spit it out.

Also: Please stop calling it cloud repatriation. That means something started on the cloud, moved to a private datacenter, and then moved back to the cloud. This phenomenon of pulling applications off public clouds and onto private datacenters (we think co-location facilities could be a better half-way means of not building datacenters and owning them) is datacenter repatriation. Thank you.

Now back to our regularly scheduled analysis. We have to riff on this piece from Andreesen Horowitz and add a few more than a few cents. This is important. This is about control, something that every business really needs.

Many of us are control freaks, and we – meaning both Tim and Nicole – have always thought this was a good thing. We like to understand the whole process of a thing and know how it all works so we can tweak it and improve it. We believe in self-reliance as well as community and sharing.

The people in today’s open source community don’t realize that there was an earlier one, which existed at the application level instead of the systems software level. But we have been around long enough to tell you about it. You can read a more detailed story I wrote back in 2012 about that other open source community at my other life as co-editor of The Four Hundred, a publication I have been writing now for 32 years that is dedicated to IBM’s AS/400 proprietary system and its progeny. But here’s the short take on it.

That AS/400 and IBM i platform peaked at 275,000 customers in 1998, and the vast majority of the midsized manufacturers, distributors, financial services organizations, and state and local governments that relied on those platforms either coded their own applications in a pretty easy to use language called RPG or sometimes COBOL or they bought applications from over 8,000 application providers who had over 25,000 software packages available. But here’s the key: When they licensed the code from vendors, it was common practice to give companies the source code. And just about every damned company I ever talked to in this base took the code and heavily modified it, making it their own, precisely and intimately tuned to their specific businesses.

They paid a lot for their AS/400 hardware and software platform, which made it very easy to use a relational database management system that was embedded into the OS and that was, in fact in the early years, the only file system on the box. (Genius, really.) And they controlled their own fate. The AS/400 had so much automation in the system and the database that it didn’t take much to administer and more times than not the programmers could manage the systems. The total cost was high for the system, but the TCO once you took all of these other factors into account was good, and they controlled their own fate.

Because of mergers, acquisitions, company failures, fashion in IT, shortages of AS/400 experts as the pool of talent has aged, and the politics of a new IT manager or CIO needing to prove something, that base has been cut roughly in half in the past two decades. But the ones that are left are diehards, and they are still programming in RPG with a healthy dose of SQL, Java, PHP, and Node.js thrown in as the platform has kept modern.

That tool stack doesn’t matter half as much as the fact that these companies invest in people and they invest in code. It’s not a heavy investment, but it is a steady one. It’s a way of life, not a fashion or a fad.

The loss of control that comes from fully embracing the public cloud is, as Andreesen Horowitz points out, very expensive. But the costs are far deeper than market capitalization, or even paying 2X, 3X, 4X or more for compute, storage, and networking woven into systems than it would cost to do it in-house. The big cost is a loss in institutional capability and the ability to conceive of and build true systems, top to bottom. We believe that businesses need to be able to do that. That doesn’t mean never using a cloud or never using its APIs or higher-level platform services. But it means making a conscious effort to build something that can evolve over time at the pace that the business needs, not that the supplier wants.

Having such capability takes money, of course. But if one thing is becoming clear, it is that the cloud is not the low cost option for running sustained workloads. Every time we do the math, it comes out around 4X more cost for the basic compute and storage capacity for mainstream applications (don’t even get us started on the network egress costs, which are egregious) and as high as 5X to 8X for certain kinds of HPC and AI systems. That’s over 36 months, and we realize it is a sunk cost on premises no matter what the utilization is. But at 50 percent utilization or so measured by wall clock time, the cloud is a bad answer for sustained workloads. Even with spot and reserved instances, even with discounts.

Getting cloud-priced IT infrastructure – HPE GreenLake, Dell APEX, and the like – and parking it in a co-lo that has better telecom and power and cooling than you can do anyway, makes more economic sense. Companies should put together their own software stacks, and they should certainly try new things out on the cloud and only burst to the cloud for production work when you need to.

Here is the other thing to consider. When you use a public cloud, you are giving Amazon, Google, and Microsoft your money to help make their own IT costs even cheaper. You do it their way, with their services, at their pace, and you are by definition always behind what Amazon and Google and Microsoft can do for themselves. If you do something interesting on your own, they can buy you or create or buy something competitive to crush you. There is a reason why Jeff Bezos has a private space program and we don’t have a decent public one. This is a very lucrative game, disrupting the economy, first in books, then in retail, then in IT. We gained a lot, to be sure, in terms of convenience, but it cost us book stores (which we love), downtowns (which we love), and maybe datacenters (which we love).

We also think there is a very high cost in the loss of expertise for businesses. And this is very hard to calculate and it cuts a bunch of different ways. First of all, all computer science and electrical engineering graduates want to do the most interesting work at the most interesting companies, and by default they gravitate to the hyperscalers and cloud builders just like they used to gravitate to the hardware OEMs and their software equivalents (Microsoft, Oracle, and such) back in the day. The talent pool is pinched, to be sure. It is expensive to find good talent, and getting more so. And many companies have thrown up their hands, moved to SaaS tools, and cobble together applications this way. But this is not like the old days in the AS/400 market where companies had the source code and then could control their own application fates. There is no building or improving or tailoring going on here. Someone else is defining the software that defines your company, and if that doesn’t worry you, perhaps it should.

Do as the hyperscalers do, not as they tell you. Control your infrastructure, control your costs, control your code, control your destiny. Or someone else will control them for you. And you will pay. Good heavens, how you will pay.