The Battle For Control Of Multi-Cloud

For the first time, Gartner published a "Magic Quadrant" for Cloud Management Platforms in January 2019 .The results are surprising, at least from my perspective, and show how different the future of "multi-cloud" enterprise IT is still viewed. Certainly, the fact that Gartner is publishing an MQ is a sign that there is significant market demand for Cloud Management Platforms. It's debatable what a "Cloud Management Platform" is or should be, but the report shows some unanswered questions in multi-cloud strategy - to what extent "cloud" can be commoditized, and which corporate functions end up controlling the multi-cloud future of IT - in what is shaping up to be "the battle of the cloud".

First, let's dive into the results of the report. I have been watching the CMP market for a couple of years, and some the vendor rankings (and exclusions) were not really what I had expected. Some examples:

CloudHealth: After the acquisition by Vmware, I would have expected them to be a leader, but instead they ended up in the "Challengers" quadrant. Why? Gartner explains:
"CloudHealth is not able to provision or create new cloud resources through its software; it only manages existing cloud resources. However, its acquisition by VMware provides access to a portfolio of cloud management offerings, including Cloud Automation Services, which offer multicloud provisioning capabilities."
Ok, so adding a layer of abstravtion to provisioning cloud resources through the CMP is essential? Let's revisit this later.

Cisco: Given Cisco's positioning of CloudCenter, it's unexpected that they are not even included in the vendor list. See Gartner's justifaction here:
"Cisco provides the required functionality through three separate products: CloudCenter, AppDynamics and Workload Optimization Manager. This combination does not qualify to provide a unified platform, per Gartner’s criteria."
So it's a unified platform we're looking for, the "one ring to rule them all"?

Cloudability and CloudCheckr: Both of these platforms are well-known in the public-cloud arena, and claim to help cloud users manage their resources in AWS, Azure and GCP. But based on the report's criteria, they have a crucial flaw in not supporting private cloud environments:
"current functionality supports public cloud providers only."
Does that mean the benefit of managing the whole hybrid/multi estate outweighs the advantage of solving specific problems that public cloud environments bring? And to what extent áre the problems of these different types of environments even in the same class?

To find the reasons for those surprising results, let's find out what view of multi-cloud strategy the report is based on. The required "Critical Capabilities for Cloud Management Platforms” raise some questions.

Is there a long-term need for private cloud environments such as Vmware and OpenStack?
I agree: not every workload is cloud-native, and the disadvantages to migrating to the cloud (cost, for example) may outweigh the benefits. However, we shouldn't assume that challenges in managing private-cloud environments are the same as managing public-environments; in fact, I think they are fundamentally different. Self-service provisioning is a big topic in private cloud environments; the needs of a central infrastructure team (balancing resource utilization, managing capacity, ensuring security, etc.) need to be balanced with needs of teams deploying on those environments. In public clouds however, self-service provisioning is built in through the APIs, and capacity management is the cloud provider's concern.

Is there a need for a layer of abstraction in provisioning cloud resources and deploying workloads?
The value of an additional abstraction in deploying workloads to public clouds needs to be looked at carefully. I am certainly biased towards towards organizations that embrace technology as part of their business model, and which use custom software to build complex e-Commerce and SaaS products. Coming from that angle, abstractions are frequently dangerous: they lead you to ignore crucial implementation details, and the reality of deploying to different environments can manifest itself through painful network latencies, data transfer costs or limited bandwidth. An abstraction should help you make good decisions, such as placing compute with the corresponding data, and deploying services based on their dependencies on other services. Arguably, AWS' strategy for hybrid cloud is a good one (with high vendor lock-in, no doubt): with Outposts, the AWS API essentially becomes the Cloud Management Platform for private and public cloud environments, and since AWS also delivers the hardware for the private environment, the API is very much aligned with how the actual infrastructure behaves.

Is there a need to move workloads between clouds?
Choosing a public cloud vendor is a long-term decision, since migrations can be extremely painful. And most organizations already find themselves in the multi-cloud world, with new cloud environments being brought in through business units, acquisitions or project partners. Being able to move workloads between environments without friction is a compelling vision, no doubt, but I believe the challenges are too high to make this a reality within the next 5-10 years. Buying into that vision requires a firm belief that private clouds and cloud IaaS providers are (or will be) fundamentally interchangeable commodities, and software can be packaged in a way that allows it to be not only deployed basically anywhere, but also moved around with no impact to users.

Is there a need for centralized control over infrastructure?
Gartner stresses the integration angle:
"The CMP proposition is that it is too tough to integrate the various cloud management functions."
If integration of various cloud management functions is at the heart of CMPs' value proposition, does it make sense to use separate solutions for, say, cost management, security and provisioning? Integration of all functions in the "one platform to rule them all" is most compelling when there is a centralized IT function that is responsible for the whole cloud estate. When ownership of cloud environments is decentralized, the value of integration becomes less clear. I will argue that choosing the best tools for specific high-priority problems, such as backup/DR or cost optimization, will likely outweight the benefits of having an integrated solution in most cases. Different organizations have different needs; if you need to solve a cloud cost problem, an excellent cost optimization tool will help you more than an integrated multi-purpose solution.

What will the mainstream implementation of hybrid cloud and multi-cloud be in the next years?
I have difficulty buying into the vision of "workloads floating across clouds". I'm certainly biased, and maybe I just don't sufficiently understand those simple, standardized enterprise workloads that have to be deployed multiple times in various clouds around the globe. There probably are many line-of-business applications that are more or less self-contained and can be easily moved, I just haven't seem them.
The environments in which I work are different: Complex application landscapes, moving substantial data, with a high need for 24/7 availability, best possible performance and user experience. I can't see those types of environments arbitrarily being spread across clouds, at least not without a serious downside.

In the last few years, at least the industry has agreed on a standard for packaging and deploying application, through containers, implemented with Docker and Kubernetes. That offers a new angle on the CMP market, though I only partially agree with Gartner's summary:
"More vendors will enter this market as newer technologies (e.g., containers and serverless) will need to be provisioned and managed in multicloud scenarios."
It may well be the other way around; with containers now the industry standard for packaging and deploying, and large investiments going into CI/CD automation of container deployment, the CMP value proposition is actually weaker - if your container CI/CD pipelines support easy deployment to Kubernetes clusters in various clouds, why put a CMP in between? It will be interesting to see how this space develops as successful and less successful multi-cloud approaches emerge.