Multicloud seems like such a great idea. It’s unfortunate that it doesn’t work. It would be OK if multicloud helped customers but vendors were hurt in the process, but the opposite is true: Vendors are cleaning up by selling multicloud snake oil while customers keep getting stuck with lowest common denominator cloud strategies and sky-high expenses.
There’s got to be a better way.
The multicloud dream
Much of what enterprises say about their multicloud strategies is complete and utter rubbish. The idea of buying into multiple clouds to pit them against each other for price negotiations is one of my favorites, because the end result of buying into multiple clouds is multiple ways to lose track of cloud expenses. Not only that, but it’s beyond bizarre to think that, hard as it is to master just one cloud, adding others somehow will result in less cost, as Steve Chambers has written:
It is an indisputable fact that to be good at just one cloud, never mind many, you have to invest in trained and experienced people, evolved processes, and new tooling and technology. This can cost millions of dollars and months of experience. Some people never get good at one cloud, [therefore…]
1: You will have much higher overheads the more clouds you have
2: The more clouds you have the more shallowly you will experience each cloud.
That “shallow” experience, in addition to increasing costs, will tend to diminish the very benefits enterprises seek in the cloud: agility and innovation. I’ve seen this up close, when the decision to embrace a second cloud sent costs skyrocketing as we straddled two clouds with our workloads. The workloads never worked as well on the second cloud as they had on the first, partly due to a lack of familiarity with the second cloud and partly because the second cloud simply lacked many of the features we needed. Worse, it became that much harder to achieve resilience and security when juggling workloads across clouds.
“But… but... but... vendor lock-in!” you say. Well, as Derek Martin posits, the idea of being vendor agnostic is just that: an idea, and one that doesn’t work well in reality:
From a strategic direction perspective, it can make a great deal of sense to back multiple horses. “No vendor lock-in,” they promise. The fallacy here is that if you don’t back a horse, you will lose all vendor safety valves the very moment you go beyond the “least common denominator” of cloud services: storage, network, compute. To some in the C Suite, we hear that this is a good thing! “We’ll be vendor agnostic and move workloads between any cloud we choose.” No. You. Won’t. And if you try, you’ll lose time, money, and, tragically, data….
The naysayer will say, “Oh, we’re just gonna use containers for everything and then we’ll truly be agile and cloud agnostic.” No. You. Won’t. All cloud providers offer a common denominator of compute, storage, and networking—this we’ve discussed. But you cannot possibly take into account all of the nuances of each cloud’s specific implementation of containerization technology or governance any more than you could have a common storage endpoint for all clouds or a common networking model for all clouds or a common.... And if you try, kernel panics and failed PODs will happen. I’ve seen it, I’ve hugged the engineers that have tried it.
In short, the reasons enterprises often cite for going multicloud don’t hold up when put into practice. And yet Dominic Briggs, Sabre’s senior director of enterprise technology operations, isn’t wrong when he said in an interview that multicloud makes sense for enterprises that want to use “particular clouds for particular workloads.” So what’s an enterprise to do?
Partnering for success
As one cloud vendor told me, “If you want consistent management across clouds, you can’t use any of the unique features of those clouds. As soon as you decide ‘I’ll use RDS or Cosmos DB,’ then all of a sudden your application isn’t portable to another cloud.”
Forced to choose, my guess is most enterprises want the higher-order services from particular clouds more than they want that portability across clouds. The latter may appeal to accounting, but the former appeals to the teams tasked with driving agility and innovation within an enterprise. If you had to pick one of those teams to appease, pick the developers. Every. Single. Time.
However, siding with developers doesn’t mean that an enterprise needs to cede control of its IT to a vendor. Rather, by going deep with a vendor, not only does that enterprise put itself in a position to develop more expertise with that cloud, but it also sets itself up as a VIP with that cloud.
Anyone who has worked in enterprise software knows that while “all animals are created equal,” following Animal Farm logic, “Some animals are more equal than others.” Vendors always tend to listen to their most committed customers, and that “commitment” isn’t merely a matter of money. The cloud vendors, like all enterprise IT vendors, will tend to partner with those customers who help them to push the envelope on innovation and publish success stories (case studies, conference keynotes, etc.).
As Martin writes, “Back a horse and become a partner to that provider, not merely a customer. Trust me, we’re looking for a few good true partners to not only help you digitally transform, but help us digitally transform with you.”
This is the right way to think about agility, security, innovation, and cost in the cloud. Multicloud sounds nice, and it offers second-tier cloud vendors hope that they can serve some niche role within your cloud stack. Don’t be fooled. Enterprises that spread themselves between multiple clouds will slow innovation and agility, not increase them, while increasing costs and decreasing security. There’s not much to love in that “strategy.”