Why multi-cloud is a lie, and here’s the truth
1 year ago
Years ago, then rPath CEO Billy Marshall coined the phrase: “The CIO is the last to know.” Marshall was referring to the CIO’s ignorance of open source, which was flourishing despite her best attempts to stamp it out. Today that same phrase rings true, but now it’s aimed at multi-cloud deniers.
Yes, Andy Jassy and Werner Vogels, I’m looking at you.
The CEO and CTO of Amazon Web Services (AWS), respectively, both denied that multi-cloud is real, insisting, as Gartner’s Marco Meinardi remembers, that “most organizations stick with one primary provider for the great majority of their workloads.” While this is undoubtedly true in the conversations Jassy and Vogels have with their executive peers, it’s very possible—indeed, likely—that a level or two down in the organization, lines of business and the developers who serve them are choosing to get their work done with whatever cloud makes the most sense.
The question is whether they’re doing this enough to disturb AWS. Probably not.
The AWS ‘everything store’
Granted, most of the time, AWS will make the most sense, anyway, given the bewildering array of services the company offers. While Google is deep in machine learning and artificial intelligence (A), and Microsoft is a strong choice for enterprises looking to maximize their existing investments in Windows, AWS offers everything from serverless database services to tooling that makes getting started with machine learning much more approachable. Amazon is building out AWS much the way it builds its retail operations: With almost too much choice.
Such choice is an unalloyed good, however, according to Jassy. As he declared from the AWS re:Invent stage in November 2017, “Customers don’t want to settle for less than half the functionality of the market leader.” The company introduced roughly 3.5 new features every day in 2017, offering up a smorgasbord for enterprises hungry to move to the cloud.
Importantly, these services increasingly move beyond the somewhat standardized world of storage and compute, with cloud-specific services like AWS Fargate that has no obvious corollary on rival clouds. Even if there were, it’s simply not possible to run a Microsoft Azure serverless function on Google Cloud, for example. This means that developers will increasingly turn to different clouds for different services (a bit like a consumer buying HBO for Game of Thrones but also subscribing to Netflix for Stranger Things).
It also means that if they want services from different clouds, they will be part of the “multi-cloud” crowd that Jassy and Vogels suggest doesn’t exist in any meaningful sense.
The multi-cloud morass
Even so, it’s almost certainly true, to their contention, that enterprises don’t invest deeply in more than one cloud. It’s simply too burdensome to do so. I therefore call into serious question Meinardi’s later point:
[W]e see that many organizations are willing to learn how to operate multiple providers. They want to do that to be able to place their workloads where it makes most sense, but also as a risk mitigation technique. In case they will ever be forced to exit one providers, they want to be ready to transfer their workloads to another one (obviously, with a certain degree of effort). Nobody wants to be constrained to work at the LCM level, but this is not a good excuse to stay single-cloud.
Nope. This is the sort of tripe that a CIO may feed Gartner (“We don’t want to get locked into Azure so we’re writing all applications to be multi-cloud”), but is 100% false in real life.
SEE: Job description: Cloud engineer (Tech Pro Research)
I’ve seen this close up: Developers accustomed to working on one cloud struggle to translate that code to another cloud. More often, developers simply can’t find the services on Google and Microsoft that they readily use on AWS. This may change over time, and it’s also true that both Google and Microsoft offer services that aren’t available, or aren’t as robust, on AWS, but the idea that enterprises are happily coding for multiple clouds to avoid lock-in is ridiculous in the extreme.
Instead, more often than not, at best we see enterprises having a declared standard (AWS or Azure, generally speaking) with stubborn pockets of alternative clouds mushrooming up all over as developers build applications on the services that make the most sense for them, given their skillsets and the desired functionality.
Companies like Red Hat aim to step in and offer a unified application layer to span multiple clouds, but even they can’t quite mute the cloud-specific services. As Expedia vice president of technology Subbu Allamaraju insisted, “There is a point of view in the community that Kubernetes will help decouple from proprietary services on public clouds. Don’t take this point of view seriously….”
Multi-cloud, in short, is always with us, but not in the sense the analysts once wanted us to believe. Companies aren’t investing heavily in multiple clouds to lower their risk profiles. Instead, they’re tending to congregate around a market leader—primarily AWS—and filling in other needs willy-nilly based on individual developer or team preferences and/or cloud-specific technologies. This isn’t likely to disturb Jassy’s sleep, but it will make life harder for the CIO.