Why multicloud management is a mess

Enterprises are overwhelmingly moving into a multicloud future, but managing that future is easier said than done.

Managing the multicloud: How to manage the new default for enterprise computing The ZDNet and TechRepublic special feature about multicloud looks at managing multiple cloud providers, how to play them off each other, and what vendors and tools can help you manage multiple clouds.

A quick search on Twitter suggests that running multicloud infrastructure is as easy as paying some mega-vendor megabucks. For example, IBM advertises: "IBM Multicloud Manager integrates all your clients' cloud environments in a single view, enabling optimal control over how they see, govern and automate everything." Just like that! No need to worry about the conflicting infrastructure, serverless applications, or any of that messy reality. Just get a bright and shiny dashboard and all is well.

Unfortunately, it doesn't work that way.

The reality of multicloud is, as Sabre's senior director of Enterprise Technology Operations Dominic Briggs told TechRepublic, companies increasingly use "particular clouds for particular workloads." Why? Because different clouds are better at certain things than others. Given that even companies that go all in on one vendor end up using multiple, how is an organization supposed to ease its multicloud management headaches?

(Hint: It's not.)

Multicloud myth and reality

Oh, sure, there's no shortage of vendors clamoring to take your money to solve your multicloud problems. Google it and, tens of millions of dollars later, you'll still have the same multicloud messiness, even if you feel better about yourself because, well, you're doing something. But what, exactly, are you accomplishing?

SEE: Managing the multicloud (ZDNet/TechRepublic special feature) | Download the free PDF version (TechRepublic)

As one employee of a major cloud provider told me, "For as long as there have been computers, there have been people trying to create abstraction layers that make applications portable across those computers, and those abstraction layers are always flawed." In the cloud, what's the fundamental flaw?

[Y]our abstraction layer either exposes the least common denominator features, which means you'll never get to use advanced features of your hardware (or cloud) platform, or else you expose the unique features of each platform, in which case your applications aren't portable anymore.

Remember Briggs' comment about "particular clouds for particular workloads?" The more an enterprise embraces serverless functions on AWS, and ML/AI tooling on Google Cloud, or Microsoft Azure for easy integration with its Windows Server environments, the further it gets from any true ability to manage applications across multiple clouds in a centralized way. As my source notes, "If you want consistent management across clouds, you can't use any of the unique features of those clouds. As soon as you decide 'I'll use RDS or DynamoDB,' then all of a sudden your application isn't portable to another cloud." 

SEE: Serverless computing: A guide for IT leaders (TechRepublic Premium)

But maybe, you say, you'll eschew this higher order abstraction nonsense to get down into the weeds with containers. In some ways, this represents real progress (and gives you more granular control), but it remains an imperfect approach: "Even if you say 'I'm only going to deal with containers,' you still have problems. Because those containers run in VMs and they use storage and networking, and the VMs, storage, and networking services are different across clouds. So you can't manage them generically."

You can opt for a tool like Red Hat OpenShift, as Sabre does, but this isn't a perfect solution. For one thing, the load balancer and storage options on AWS are different than those on Google Cloud Platform or Azure or on-premises. There are different options, different configuration fields, different object names, and no (are you listening?), no silver bullets that will bring magical order to this chaos. Period. 

Or, as my source undiplomatically put it to me, the whole multicloud management hype is "total BS." 

And yet….

Minding the cloud gaps

Kubernetes does offer some hope. Even taking into consideration my source's concerns, Kubernetes provides "an extremely generic abstraction [whereby] we take the minimum of all clouds," as Citus Data (now Microsoft) executive Craig Kerstiens has suggested. This isn't the ideal, but it does get us part of the way toward that ideal. For the ideal, according to John Marchese, we'd need the cloud vendors to see it in their interest, which they don't: "IF the disparate cloud vendors wanted it to happen it would be assured and relatively simple. Since that isn't the case, it's a challenge but will certainly be achieved across a portion of the spectrum even without cooperation."

During this "non-ideal" transitional phase, Briggs has advised, there are Kubernetes-based tools like Red Hat OpenShift to smooth over multicloud messiness. As he put it to me, Sabre hopes the industry will "get to a point where cloud infrastructure is truly commoditized." We're nowhere near that world yet, so OpenShift "gives us a layer of abstraction that allows us to port workloads between" its chosen clouds, AWS and Azure. Not content to leave it there, Sabre is "building additional things around monitoring, security, etc. that then make the application deployment reusable and abstracted from the underlying infrastructure."

VMware, too, offers tools that can help (some of which are, like Red Hat, built on Kubernetes). To help ease multicloud nightmares, VMware offers tools like CloudHealth, Wavefront, and VRA, which are able to manage native services on each cloud platform. VMware also offers tools to help ease hybrid cloud (mix of on-premises and cloud), with a focus on bringing the vSphere platform to run on the native clouds (e.g., VMware Cloud on AWS). In this way, VMware is helping to standardize a company's operating model, but it doesn't ease the problem that you're still limited to the features and functions of vSphere on each of those clouds. So if you want to use something like Amazon RDS, you're back to multicloud.

SEE: Quick glossary: Hybrid cloud (TechRepublic Premium)

And with multicloud, you're back to either swimming in the base-level functionality of each cloud (multicloud management FTW!) or you're (more likely) taking advantage of the higher-order services within each cloud (multicloud mismanagement oh no!). You can listen to smart folks like Deloitte's chief cloud strategy officer David Linthicum, and get up to speed on all the tools and strategies for trying to route around that mess, but, quite bluntly, it's going to remain a mess. 

This isn't to suggest that multicloud is a bad idea; actually, it doesn't matter if it's a good idea or a bad one--it's simply how enterprises function in the modern age when developers can spin up cloud services with the flick of a credit card. Roughly 80% of all enterprises are steering toward multicloud; the other 20% are kidding themselves. As such, smart enterprises are looking to Kubernetes (perhaps OpenShift?) to try to abstract away some of the complexity a multicloud environment introduces, while using tools from VMware and others to try to manage native services in a somewhat centralized manner. It's not perfect, but it's a start.

Also see


Image: iStockphoto/gorodenkoff