Why cloud workload portability is a pipe dream

Nobody likes lock-in, the risk of which has dogged the public cloud from the start. But even in the container era, can it really be prevented?

Why cloud workload portability is a pipe dream

At last week’s AWS event in Santa Clara, California, Amazon GM of product strategy Matt Wood gave a rousing recapitulation of the abundant services offered by the world’s leading public cloud, from good old Elastic Map Reduce to Kinesis to AWS Lambda to the ruggedized AWS Snowball box for shipping data via UPS 80TB at a time. When you hear this litany, it’s hard to avoid wondering how other clouds can catch up in the sheer number and variety of services, let alone in market share.

At the same time, Google and others maintain they're hearing enterprise customers say they don’t want to put all their eggs in one basket and are spreading their bets across multiple clouds. In a recent conversation with CloudHealth Technologies, an IT service management provider for the cloud, I heard a slightly different spin: Different parts of enterprises tend to choose clouds for tactical reasons -- so an uptick in the adoption of multiple clouds tends to be "strategic" only in hindsight.

Either way, subscribing to multiple clouds doesn’t mean you’re going to move workloads among them. CloudHealth’s monitoring services gives the company a clear view of what customers with multiple clouds are doing, and although CEO Dan Phillips has read speculation in the tech press about “everyone moving their workloads back and forth,” he says, “it’s just not happening.”

It’s easy to see why. Sure, Docker and container management and orchestration solutions have made portability vastly easier, but as soon as you start availing yourself of the special services of whatever platform you’re on, you’re hooked.

Take Hudl, a cloud-based SaaS offering that coaches and athletes use to review game footage. It’s a .Net-based shop that was built on AWS before Azure was available. Hudl CTO Brian Kaiser took a hard look at Azure when it launched, and he found its PaaS model too restrictive. He told me Azure has evolved to become “an amazing and compelling product, but it’s not compelling enough for me to consider switching. There’s a lot that they do, but I don’t think they do enough different or better to make me seriously consider it.” Kaiser happens to be a huge fan of the data warehouse service Amazon Redshift, which he says Hudl uses for “everything.”

Seriously, what incentive could shake a happy customer from that sort of dependency?

Now, a nine-year-old, cloud-native business like Hudl might not be a fair example. There are many more generic workloads. As Google cloud product manager (and founder of the Kubernetes project) Craig McLuckie told me:

We’re making a significant bet that we can help our customers make this transition from a VM-centric world to a container-centric world. Once they’ve made that transition, they’re no longer tied to the locality of where they’re running their infrastructure. So as part of that transition, their workloads are liberated and they can then pick a destination based on the needs of their workload and the quality of service.

Naturally, McLuckie thinks this will give Google an advantage. But what about the proprietary features every public cloud offers and customers come to depend on? McLuckie acknowledges their value, but “what we’ve learned is that our customers want an open ecosystem. They want to access services from a broad array of providers. They don’t want to be tied into a specific cloud provider’s infrastructure.”

That impulse sounds very familiar: People always say they hate lock-in. On the other hand, public clouds -- including Google Cloud Platform, as McLuckie readily acknowledges -- tend to differentiate by offering proprietary features. Use them and you're hooked. The platform on which you build an application has a tendency to be where it spends its useful life, be it in the cloud or on your own data center’s servers.

Copyright © 2016 IDG Communications, Inc.

How to choose a low-code development platform