The Wrong Way To Think About IT

Andreesen Horowitz investors Sarah Wang and Martin Casado recently argued that moving to the cloud hurts profit margins and could cost public companies as much as $500 billion in collective market cap. It’s a bold, controversial claim. It’s also wrong.

Or, more politely and accurately said, their focus on cost savings may be the right answer to the wrong question. “Cost optimization always takes a backseat to decreasing time to market/feature velocity” with enterprise buyers, Duckbill Group Analyst Corey Quinn countered. Not sometimes. Not often. Always. “Fundamentally, companies that focus more on cost optimization/reduction than they do growth tend to be companies in decline,” Quinn continued.

In other words, the right question isn’t “cloud or on-premises?” Enterprise IT is too messy for facile answers to binary questions like that. The right question is “Which approach (among these or others) gives a company the maximum ability to invest for growth?”

The repatriation fever dream

Wang and Casado work for one of the world’s most successful investment firms. They are in the business of helping companies grow and then profiting when those companies go public or get acquired. They’ve put a lot of thought into their thesis. In brief, their theory is: “while cloud clearly delivers on its promise early on in a company’s journey, the pressure it puts on margins can start to outweigh the benefits as a company scales and growth slows.” As a consequence, they suggest that cloud costs public companies as much as half a trillion dollars in collective market cap.

That’s a lot of money.

They suggest that startups build optionality into their architecture from the start. Companies should architect their infrastructure in such a way that it becomes easier to “repatriate” workloads from cloud back to on-premises data centers when the cost of doing so makes sense.

It’s a nice thought, but it’s completely impractical. Enterprise IT simply doesn’t work that way in the real world. No one moves workloads to the cloud on a whim, and no one moves them back on another whim. There’s all sorts of inertia to complicate those plans, including the technology to do it. And no, Kubernetes isn’t some panacea that magically moves workloads between clouds or between a private data center and the cloud, something I’ve highlighted before.

This is one reason cloud, despite being a big deal, is still just 5% to 6% of global IT spending. Before you say “but Dropbox did it,” Dropbox isn’t a model most companies can follow: It moved one niche application to its private data center with the kind of resources virtually no other companies have. It’s not a poster child for repatriation.

There’s also the separate problem that Quinn pointed out: “By building for a theoretical exodus, you pay for optionality with feature velocity and reduce your chances of getting to a position where the cloud costs even matter to your business’s overall success.”

But wait, there’s more!

Making expensive people do basic things

Subbu Allamaraju runs the teams that build Expedia’s search and discovery products. The first problem he lists with the Wang/Casado argument is the Kubernetes critique I mentioned above: “There is no tech that can help repatriate. The Kubernetes reference is a lie we tell ourselves.” Allamaraju isn’t saying that Kubernetes doesn’t have value—far from it. He’s arguing against the idea that Kubernetes makes all apps fungible between operating environments.

That’s a damning indictment of Wang and Casado’s argument, but Allamaraju goes further.

The bigger issue is people. “Companies that operate successfully (high agility and manageable costs) on-prem must spend upwards of three to five years of some of their best engineering talent to mature their core infrastructure (start with the primitives) architecture and engineering. Very few can afford this,” he argues. Even if your company can afford it, would you really want to? After all, Stedi Cofounder and CEO Zack Kanter says that to rebuild the cloud to save some money means you’re accepting the “(long-term devastating) cultural cost of recruiting world-class engineers to do undifferentiated heavy lifting.”

Even if you somehow manage to retain engineers tasked with building base-level cloud services (compute, storage, etc.), you’ve missed the point of the cloud entirely, Kanter and Quinn both stress. The real value of building on a public cloud is the higher-level services, not necessarily the basic building blocks. By the time you replicate those lower-level services, you’ve spent years losing out on the higher-order bits.

Allamaraju finishes by seconding something Quinn said above: “To be successful at scale in a hybrid architecture and maximize customer value, cost efficiency, and agility requires you to make a large number of technical, people, and process decisions upfront years before needed. Even if you can afford this, you’re unlikely to get these right.” It sounds great to think a decade ahead in one’s infrastructure to build in long-term optionality. It’s also a pipe dream. Yes, there are things we can and should do to preserve architectural agility. But Wang’s and Casado’s recommended approach costs too much to achieve too little.