Multi-Cloud is (Mostly) a Waste of Time

Have you heard? Multi-Cloud is the next big thing, replete with rainbows and unicorns to help enterprises bridge the gap between cloud providers. If the hype is to believed, It’s time to put away all the legacy marketing swag you collected touting public cloud, private cloud, hybrid cloud, and even anti-cloud and go all in on multi-cloud.

If you haven’t figured it out, I am not a fan of the multi-cloud trend. The problem is that, as is so often done in the IT industry, everyone wants to be the first to define the “what” and the “how” of multi-cloud without first exploring the validity of the “why.” So, I want to briefly explain some reasons why I think a multi-cloud approach is a waste of time for most users. I will caveat that a bit by saying there are always exceptions where a use case justifies a multi-cloud approach but it’s probably not the case of most of you.

Before that, we should probably define our terms. When I talk about multi-cloud, I have in mind the broad but generally accepted definition of multi-cloud as an approach where users leverage services from two or more public cloud providers. For example, an organizations may choose to run cloud instances in Amazon Web Services (AWS) but also run containers on Google Cloud Platform and vice versa. This differs from hybrid cloud where users leverage services from a public cloud along with deploying and operating, in their own data center or in a co-loc, some infrastructure they call a private cloud. And if you are running two private cloud stacks with no public cloud provider in the mix, then we should probably just call it “legacy enterprise IT with a mandated cloud initiative.”

So why is multi-cloud (mostly) a waste of time? I am going to approach this by addressing, in turn, the three most common arguments I hear for multi-cloud.

• Geography and Latency Requirements — Some vendors and analysts say that you need to use multiple cloud providers to ensure you can deploy workloads in locations that are closest to your users. That was a valid argument circa 2012 but today AWS has services in 20 Regions across the globe, GCP in 19 Regions, and Microsoft Azure has 54 Regions. That doesn’t take in account each provider’s content distribution network which further helps to address potential latency issues. With each of the big three providers continuing to expand their global footprint, it’s very unlikely you won’t be able to deploy your workload in the right geographic location with any of these providers.
• Mitigation Against Cloud Outages — The argument goes, you can greatly increase the availability of your applications by deploying them across two cloud providers or backing up data from one cloud to another cloud. First, let’s analyze the idea of a cloud outage. This seems to be an idea held-over from the days when people had trouble differentiating a cloud from a single data center and before folks really understood how to leverage multiple Available Zones(AZ) and Regions. While services in AZs and even Regions have failed, we have never seen any of the big three public cloud providers completely fail. That has to do with how these providers design and implement their global architecture to ensure resiliency of their cloud. I’ve said before that if a cloud provider, like AWS, completely fails, we probably have bigger concerns than the availability of our applications, like perhaps coping with a Zombie apocalypse.

The key is to understand the global architecture of your cloud provider and designing your application to leverage their multiple Availability Zones and multiple Regions. This is how Netflix, for example, was able to continue serving videos a few years ago after an issue with Amazon S3 in the us-east-1 Region. I also addressed this in a previous blog post. Someone might argue they could just architect their workload to fail-over to another cloud provider. Guess what? In disaster, you want to keep things simple. If the odds an outage of two Regions in the same cloud is unlikely to ever happen, then you are likely only adding unneeded complexity by trying to design your application to run across two clouds instead of just across two Regions.

• Avoidance of Vendor Lock-in — Lock-in happens when the cost of switching is greater than the cost of staying put or when you are compelled to not switch because of the value you currently receive from your provider. Frequently, you get locked in because both realities are true when it comes to the public cloud.

I frequently get questions from users asking about the feasibility of replicating or backing up data from one cloud provider to another. My first response has always been to ask, “Why, what are you trying to accomplish?” If the reason is to protect against a cloud failure, I walk them through the reasoning I outlined above to determine if what they are looking to achieve can be done in a different way using a single cloud provider. If the reason is they believe having their data in two different providers prevents vendor lock-in, then we walk through the costs/benefits of switching vs. staying.

Moving data around is hard. I and many others other before me have written about the impact of data gravity and how difficult it is to move large amounts of data and their accompanying applications between locations. It’s not just about obvious costs such as bandwidth and cloud egress charges. You also have to factor in the cost of maintaining a second environment and staffing one or more teams that can operate two different clouds. Note.. I am not talking about a one-time migration but an approach where you think you will be moving back and forth between clouds depending on which cloud provider has the lowest costs. This approach is sometimes called cloud arbitrage.

More likely, you are not looking to move data back and forth between clouds. Instead, you want to keep the providers honest by either running different applications in different clouds or running the same application but split across multiple clouds. This will supposedly keep providers from raising prices since you have shown you can always move your application completely from one cloud to another. Putting aside the fact that cloud providers have historically lowered prices as part of their business models and the economics of why and how this works, let’s just talk about the technical trade-offs that have to be make to be truly multi-cloud.

Setting aside the issue of data gravity, building your applications to be portable across clouds likely means you want to avoid leveraging cloud services beyond the base compute, storage, and networking services. For example, instead of using a cloud provider’s managed database service, user might choose to run their own database using cloud VMs. The trade-off is that you don’t get to leverage all the innovation that cloud providers have in their advanced services and you continue to bear the burden of maintaining a large portion of your application. If the reason to move to the cloud is to be agile, then putting yourself in a situation where you aren’t leveraging innovations from a provider that likely has more engineering resource than you have and where you have to operate your own databases, for example, would seem to work against this objective of being more agile.

It could be the case that someone is not looking to make their applications portable across clouds but just want the flexibility of having multiple clouds and has no issues with using advanced service from any of their providers. Then I would go back to asking, “What are you looking to accomplish?” And I would raise the questions of, “Are the benefits of a multi-cloud approach, in this scenario, worth the cost of maintaining operations across two clouds?”

Hopefully, I’ve convinced some folks to reconsider the trendy multi-cloud approach. There are more arguments to be made which I don’t have the time to get into, but the reality is that many, maybe most of you, have already committed themselves to multi-cloud. The reasons can range from “We’ve done the analysis and this makes justifiable business sense,” to “The analyst I paid told me it’s the way to go,” to “We’ve always had a dual-vendor approach and we are sticking with it.” Fine, just do yourself a favor and work with your business folks to consider if multi-cloud makes actual sense from a cost and an opportunity standpoint.