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 , as blogger Cloud Pundit has observed.

, 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 :

, “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.