Today's hybrid cloud looks more closed than open

We’ve had convergence towards hybrid clouds and ‘universal’ applications, but now we are seeing divergence towards different cloud platforms, each offering its own flavour of interoperability. What’s going on?

I’ve seen the hybrid multi-cloud, and Kubernetes or not, in some ways it’s almost as closed a platform as the traditional IT and proprietary public cloud models that it seeks to supplant.

Of course it can still offer significant advantages for anyone used to traditional IT. Develop the same containerised or serverless app once and run it in a private cloud on-site, on systems hosted at a co-location centre, on a private cloud hosted by a cloud provider, or in a public cloud. Interoperate between them, move tasks and microservices around for workload or cost balancing, and so on.

The big difference versus traditional architectures and locked-in clouds is where you have to make your proprietary choices. With hybrid multi-cloud you can have pretty much whichever hardware, DevOps tools and public clouds you want, for example. Where you need to make a commitment is between those, in the middleware layer that glues it all together and converts your Dev expenses into lovely Ops revenue.

Day Two is when ‘seamless’ really starts to matter

That’s because you can only get all that seamless hybrid goodness – for now, at least – by running the same Day Two orchestration and management tools everywhere. That in turn means you need to pick a single ‘multi-cloud management layer’ for all your clouds, public and private.

In effect, you need the same ‘hybrid operations platform’ everywhere, be it from VMware, Nutanix or Red Hat – and you can slot Microsoft Azure, Google Anthos and others in here as platform options, too.

This proprietary-hybrid model might well change in the future if relevant new standards appear quickly enough, and it’s already an improvement on the past, certainly as far as Kubernetes containers and pods are concerned. We don’t get write-once run-anywhere, because sideways portability between different hybrid platforms isn’t always straightforward, just as it isn’t straightforward between the major public clouds. It can still be very useful though, and perhaps we can call it “write-once run-manywhere” instead.

Have you hit hurdles with hybrid interoperability? Or do you disagree it’s a problem at all? Tell me in the comments below.

Content Continues Below