Your CEO may have proclaimed your company is “all in” on cloud provider X at its recent event, but don’t be fooled. Your organization is irredeemably multicloud. How do I know? Because every enterprise of even moderate size is multicloud by accident if not by design. That’s just how enterprise IT works, and it’s why I’ve suggested that learning a second cloud, like learning a second language, can be great for your career.
And yet, multicloud comes with costs. As such, as former AWS executive Tim Bray recently wrote, the best cloud strategy is whatever makes your people most productive. Hint: That may well involve standardizing as much as possible on a single cloud provider. But that’s aspirational.
Multicloud by happenstance
Today you’re running services from multiple clouds. The CIO may not think so, but with the spread of open source in years past, the CIO is not in the best position to know all that’s going on within the enterprise. Developers, pushed to deliver applications and infrastructure at ever-increasing velocity, are going to use whatever contributes most toward that goal.
Sometimes that’s going to mean BigQuery from Google. Lambda from AWS. Azure Kubernetes Service from Microsoft. Any number of different services from these or other clouds. Heck, even the most “basic” primitives like compute and storage are dramatically different between clouds, and your developers are going to have a familiarity (and preference) for one over another.
So, yes, you’re multicloud whether you want to be or not. The question is whether you should be.
Optimizing for people
An oft-forgotten truism in IT is that people, not hardware or software, are the most expensive (and valuable) asset within an organization. Back in 2008, Jeff Atwood, founder of Discourse and Stack Exchange, highlighted this fact: “Even the most rudimentary math will tell you that it’d take a massive hardware outlay to equal the yearly costs of even a modest five-person programming team.” As he says another way, “Hardware is cheap—and programmers are expensive.” The same is true of software.
It’s not just the salaries of the people involved, though. One corollary I’d add to Atwood’s aphorism is, “Hardware (or software) is a commodity—people are valuable.” People can thoughtfully figure out how to optimize software or extend the life of hardware. People innovate in ways that hardware and software don’t.
This brings us back to Bray’s argument.
Yes, companies may choose to go multicloud or end up there despite their best intentions. Even so, he stresses, it pays to “go all in on a public cloud platform and use the highest-level serverless tools as much as possible” because “every time you reduce the labor around instance counts and pod sizes and table space and file descriptors and patch levels, you’ve just increased the proportion of your hard-won recruiting wins that go into delivery of business-critical, customer-visible features.”
In other words, the less time your developers need to spend figuring out the ins and outs of different clouds, the more time they can spend innovating on your customers’ behalf.
The downside to trying to architect your way out of lock-in is that you lose all the time that could otherwise be spent building. “If you go all in, there are pretty big payoffs,” Bray notes, like incredible scale, resilience, and more. Sure, “you can decide you’re just not up for all these proprietary APIs,” he continues, “but then you’re going to need to hire more people, you won’t be able to deliver solutions as fast, and you’ll (probably) end up spending more money.”
All this is not to say that multicloud is wrong for your enterprise. Rather, it’s a suggestion that the right strategy will always be about optimizing for the productivity of the people you have on staff or want to hire.