Multi-cloud is the new cloud ... or is it?

“Multi-cloud” is the new hot term for cloud conversations. Most Enterprises are still struggling to get the most of their cloud (agility, scale, cost, performance, etc.) but today, it looks like you need to have a MULTI-cloud strategy.

Let’s go straight to the point: in most cases, multi-cloud is a waste of time, is counterproductive and is delaying a sound cloud strategy. At least, the decision to go multi-cloud should not be taken as granted and should go through extensive scrutiny.

But, before discussing the arguments, let’s first define what multi cloud is all about. You will find plenty of surveys giving you the percentage of Enterprises running “multi-cloud”, giving the impression that the debate is over. But what exactly are people referring to when they talk about multi-cloud? Well, it all depends on what you include in “cloud”.

Multi-cloud? Which multi-cloud?

Some studies are including SaaS solutions in their result and state for example that 15% of cloud adopters work with at least 10 cloud providers. For example, let's say an Enterprise uses MS Office 365, Salesforce, Gitlab and in addition is operating a private cloud and using a public cloud. Et voila ... they are already using 5 clouds. That’s ok, but so what? SaaS being a vertical market, it is obvious that Enterprises will use more and more SaaS, so using plenty of different "clouds".

But I suspect this is not what most proponents have in mind when they talk about multi-cloud!

Other studies only refer to IaaS/PaaS and include private and public clouds. See the chart below from the -excellent- 2019 State of the Cloud Report delivered by Rightscale and Flexera.

Here you notice that 69% of “multi-cloud” (58% out of 84%) refer to hybrid cloud configurations. Nothing wrong, but nothing new. We know for a while that the typical cloud landscape will be hybrid in a foreseeable future.

But customers I am discussing with, are talking about multi-PUBLIC-cloud and try to understand is they need to go this way. This is what I will be discussing in this article. Most of today’s narrative about multi-cloud is on cloud independence, how to avoid cloud lock-in or how to combine the best of multiple public clouds. When you read the articles on Internet or the marketing material from several vendors, it seems a natural and obvious idea, and it seems that surveys tell us that all Enterprises are acting this way. But let’s come back to our diagram above:

• Multiple public clouds are used by 17% of the Enterprises (2019 Cloud Report)
• It is decreasing from last year (21%, 2018 Cloud Report), so multi-public-cloud is not "exploding"

In addition, we need to consider that many multi-public-cloud situations were inherited from shadow IT practices, mergers and acquisitions, and that these Enterprises are now fighting hard to recover some governance.

So, the question is :

Is multi-public-cloud an obvious strategy that we need to take for granted? Or is it a not-so-obvious proposition, mostly pushed by cloud management platform vendors or other CaaS and PaaS vendors to fight the cloud disruption, stay in the game and possibly control Enterprise accounts?

Multi-Public-Cloud through a benefit / risk exercise

It is a real challenge for most Enterprises to use Public Clouds at scale, and to extract full business value. Getting high agility, ultimate scalability, speed and simultaneously mitigating the associated risks turns out to be challenging, and requires hard work to address governance, technical, financial and operational issues. It took years to companies like Netflix to be at the level they are today with their cloud operations. And it is still an ongoing work.

Enterprises have decades of experience to run data centers, but Public Clouds are different, and the learning curve is steep. Hyper-scale cloud providers have 100s of services, each with 10’s of features, and you need to learn how to take advantage of them. Fortunately, the investments you make to leverage further your cloud brings usually great paybacks.

If you go for multi-public-cloud, you usually need to duplicate many of the efforts mentioned here over. Or you need to abstract the clouds behind another layer of technology. Are these investments worth it? Let’s analyze the reasons pushed forward by multi-cloud proponents.

Avoiding cloud lock-in

I hear this argument as the number one argument for going multi cloud.

Let’s first recognize that Enterprises have been locked in technologies for decades. They have been locked in mainframes, in databases, in ERPs, in application servers, in applications (they will now be locked in SaaS), in network equipment, in servers, in hypervisors, in languages (Cobol somebody?).

And now, ladies and gentlemen, for the first time you are told that it is possible to avoid technology lock-in, for something as big and as complex as your IT infrastructure!

Forgive my sarcasm, but this looks like wishful thinking.

So, if you don’t believe in unicorns, a proper lock-in discussion is about evaluating the benefit of using a technology against the cost of the technology + the cost of reversibility. And as usually, the evil is in the details.

• If you only use the common cloud denominator (I’ve seen this strategy pushed within many Enterprises), you will not leverage managed middleware (database, queues, etc.) or managed control planes (Kubernetes, App mesh, Hadoop/Spark, etc.) which usually provide the best return on investment. Take the example of a managed database (Google Spanner, DynamoDB, etc.). Some customers tell me that they prefer to get VMs and install an opensource version of the database, which is something they can easily replicate across different clouds. I challenge this statement: you need to balance the cost of installing, operating and maintaining your database + the cost of using a less polished technology (less scalable, less redundant, less secure) against the cost of the managed database + the cost of your exit strategy to another cloud. Basically, using cloud’s lowest denominator is about considering cloud as a simple hosting facility.
• You can install a multi-cloud management platform or a Kubernetes platform or any other PaaS platform (like Cloud Foundry). However:

1. You will be looked in to the vendor which is selling you this layer
2. And you use the common cloud denominator because this layer is abstracting all the clouds. For example, the cloud native Kubernetes integration provides performance and efficiency advantages over external Kubernetes platforms installed on cloud VMs (will be discussed in another article).

• Cloud provider are rivaling on governance tools, cost management tools, devops tools to help you better focus on your business. If you don’t use them to avoid lock-in, you are incurring penalties against your competitors who are using them. I went through a comparison between installing the common Gitlab/Jenkins tools in the cloud and the cloud native repositories and CI tools. Given that you must maintain and scale your tooling when you install yourself, and considering the cost of reversibility, the advantage goes to the cloud native tools.

Disaster Recovery

Customers tell me that they can’t afford the risk to run mission critical application on a single cloud.

Today, hyper-scale cloud provider (AWS, GCP, Azure, Alibaba, IBM, Oracle) have 10’s of regions and at least 3 availability zones in most regions. This means that you can design high availability and disaster recovery at your convenience, and at the best cost. There are plenty of Enterprises running at scale and with an unprecedented level of availability and performance on a single cloud. I personally thing that if you operate applications at the level of Netflix or Amazon.com, you are leading the pack.

But what if an entire hyper-scale cloud provider runs out of business? This could happen for political or economic reasons. Here the right calculus would be to compare the mathematical expectancy between the 2 issues: cost_of_multi_cloud*(1-probability_of_cloud_failure) against cost_of_exit_strategy*probability_of_cloud_failure. I did not do the math, mainly because the probability of a hyper-scale cloud provider failure is unknown (it is a “black swan” type of event). But did you do the math when you went with IBM mainframes? Or Oracle application servers and databases?

Pricing

Some customers tell me that, if they run a multi-cloud setup, they will be able to choose the best service prices (For example one cloud could be competitive on VM prices, and the other one on serverless). Globally, the hyper-scale cloud providers are adjusting their prices to stay competitive on the market, and I don’t see excessive variance across different services.

Again, you need to estimate the potential gains from this strategy against the cost of running multiple clouds.

Also, bare in mind that cloud have many ways to give you volume discounts, so you need to consider that is you split your expenses across multiple clouds, you will likely not get the best volume discounts.

Different clouds for different tasks

Another argument is that cloud provider may have different strengths and it could be interesting to take advantage of the best of breed solutions from every cloud provider. In fairness, this argument is the best I heard for now, and it is one of the reasons why several companies are already using different cloud providers.

However, this usually does not imply that you need to define full multi-cloud operations. Cloud services are ranging from base infrastructure services (VM, network, storage) to middleware as a service to high level technological services (IA, blockchain, etc.). But networking features, serverless, containers, Kubernetes only differ on details, and usually cloud providers are closing the gaps very fast to stay competitive. It is only when you use high level services that you find significant differences between cloud providers (For example AI, Blockchain, Iot platforms). And it this case, we have low coupling; it is just an API that you call from your application.

For example, application running on AWS could easily call IBM Watson image recognition service if it makes sense (Many other APIs exist on the market, this is simply the API economy).

Reasons to go multi-public-cloud

So, it really looks like there are no compelling evidence to go multi-public-cloud. However, it is always safe to spend some time assessing the strategy in detail, because every Enterprise is different. There are software companies whose customers ask to run their code on different clouds (I have examples with core banking software and energy management software). It is not SaaS, their customers want to have a single instance running for them, and they would like to choose the cloud and the data center.

But I guess that in most cases, the multi-public-cloud is not a good bet, as benefits/risks ratio are usually not favorable, especially if the Enterprise cloud maturity is low. In this case, a better strategy is to invest heavily into augmenting the cloud maturity rather than divesting effort, resources and investments into a multi-public-cloud strategy.

Once you are very mature in your cloud operations, it will always be time to include additional capabilities from other clouds.

What is your opinion on multi-cloud?

This article first appeared on my blog