People talk about multicloud as if it's a choice. It's not. Multicloud is simply a fact of life.
Within any enterprise, developers move at different paces while dealing with years or even decades of legacy build-out. Some workloads will never go anywhere. Others simply fit a particular cloud best or migrate to the cloud where a certain dev group has already established a beachhead. Through whatever means those workloads arrive on AWS, Azure, Google Cloud, or another public cloud, and they'll very likely stay put once in place.
One factor keeping such workloads firmly rooted in place is data gravity. It's expensive to move data from one cloud to another (not to mention from an on-prem deployment to a public cloud). But that's not the biggest problem. The primary issue with multicloud deployments is that each cloud comes prebaked with unique services—and those services ensure lock-in as far as the eye can see.
You call that agility?
Early on, multicloud was touted as a strategy to build resiliency into IT infrastructure or to create leverage in negotiating pricing. Yet the whole notion of seamlessly moving workloads from cloud to cloud has turned out to be a bit of a pipe dream, as blogger Cloud Pundit has observed.
Instead, multicloud has sprung from developers building applications wherever and however they've made the most sense—a little Google Cloud here for TensorFlow machine learning; a little Azure cloud there for the .Net support, and so on.
Managing this multicloud reality is tough. Escaping it may be impossible. This is partly a matter of data gravity. But as Heptio founder and CEO (and former Google and Microsoft cloud architect) Craig McLuckie posits, data gravity "is technically easy to solve. Amazon demonstrated at the recent Re:Invent that there is nothing in the world that can move data more quickly than a semi truck full of hard drives." Pricey? Maybe. Possible? Definitely.
The first hit is free
The far thornier issue, however, is service dependence. McLuckie continues: "Detangling your infrastructure from deep service dependencies will likely be even more difficult than getting your data out of a cloud provider's offering."
The easy but futile response: "Don't build on those cloud-specific services." Good luck with that. As RedMonk analyst James Governor notes:
In an age of serverless, PaaS, and microservices ... developers make use of whatever is nearest at hand to solve a problem. The swift adoption of Amazon Lambda shows just how attractive an event-based model for taking advantage of cloud platform services can be, and with great power comes great lock in.
Governor gives kudos to AWS for Lambda, but Google and Microsoft have their own amazeballs services that no one else can touch. Urging developers to steer clear of these services and stick to generic, lowest-common-denominator storage and compute services simply won't work.
Indeed, as Expedia vice president of Technology Subbu Allamaraju argues, "The value of any public cloud is in the platform aspects and not the basic primitives. Abstractions to prevent lock-in introduce operational complexity and limit you to common denominator primitives like virtual machines."
No one wants that ... not really.
Escaping a cloud
That said, there are ways to mitigate lock-in. One solid piece of advice from McLuckie is to prioritize services that are based on an open source project (such as Kubernetes) and to "be judicious about betting on services" that are not.
McLuckie also points to nascent efforts like the Open Service Broker API as a harbinger of cloud freedom to come. In his view, you should "think about using formal service abstractions that allow more control over which services are made available to your engineers."
Introduced in December, Open Service Broker is a promising idea, with Red Hat and Pivotal (which originated the Service Broker) incorporating the API into their PaaS offerings and collaborating to improve it. Google and IBM are also on board. If Open Service Broker takes off, enterprises could maintain a consistent programming interface for developers, even as underlying services from different origins are swapped out (although with some pain).
Such interoperability is the next big cloud battleground. As the big-three cloud providers duke it out for hegemony, other vendors are stepping in to help enterprises make sense of multicloud realities. The winner will be the vendor that can slightly ease the ache of this painful reality.