Why Multi Cloud is a waste of your time and resources

Posted in Cloud, published on

There has been a lot of talk about Multi Cloud in the past years. The recent launch of Google Anthos has only increased chatter on the topic.

In this article I want to share my views on Multi Cloud and why I think it's a waste of your time and resources.

What is Multi Cloud?

Like all new technologies, the definition of Multi Cloud mostly depends on who is talking about it or what vendor is trying to sell you stuff. I don't want you to confuse this term with a Hybrid Cloud.

When I talk about Multi Cloud I mean a cloud architecture that uses multiple cloud providers such as AWS, Azure or GCP. For me Hybrid Cloud refers to a combination of On-Premise infrastructure (classic virtual machines or private cloud) and a public cloud infrastructure such as AWS.

To put it simply: Multi Cloud is a mix of public cloud vendors, Hybrid Cloud is a mix of public cloud and (legacy) On-Premise infrastructure.

Reasons for choosing Multi Cloud

Why exactly do people think they need a Multi Cloud architecture? A lot of people I talked to say they don't want to depend on a single vendor.I can agree up to some point. Being dependent on a single vendor can be a bad thing, but this needs to viewed in the right context.

Not so long ago the idea of Vendor Lock-In was truly terrifying. Back when Microsoft was inevitable in Enterprise IT or when Oracle was the database, a lot of companies paid a high price because they were locked in.

But when it comes to the cloud we are dealing with an entirely different vendor landscape. The three big clouds, AWS, Google Cloud and Azure are at each others throats and keep pushing out more features, lower prices and better developer tools. The Cloud is an area where there isn't a single vendor that is dominant or unavoidable.

So going all-in on AWS or Azure isn't a Vendor Lock-In in the traditional sense. Microsoft isn't going to jack up their prices overnight and triple your cloud bill (that honour is going to that one dev who spins up 50 instances instead of 5 ;-).

Pitfalls of Multi Cloud architecture

One of the biggest reasons I don't recommend and actively guard against a Multi Cloud architecture is that you cannot fully maximize your investment of going to the Cloud when you have to architect for multiple vendors.

When doing things right and choosing a Cloud-Native Development approach you want to take advantage of managed services and tools provided by your cloud provider. This means taking advantage of services such as AWS SNS, which provides a pub/sub messaging services. If you want to design a Multi Cloud architecture on AWS + GCP, that means using GCP Pub/Sub along with AWS SNS.

There are of course a number of solutions to this issue. You can architect around the managed services and abstract them away from your architecture, or roll your own messaging service.

Rolling your own

Avoiding a managed service from a cloud provider because you are going Multi Cloud and then rolling your own alternative is just nuts. Unless you are FAANG scale I doubt you can do a better, more cost effective job than the folks over at Amazon, Google or Microsoft. And what is the point of going to the Cloud if you are just going to roll your own services? Might as well stick to a colocation box and be off much cheaper.

Abstracting away Cloud services

While I still view this as an argument against Multi Cloud this is still a good thing to do. Programming is all about abstraction, at every layer. So you should definitively abstract away your link to AWS SNS just to hide any peculiarities or complexities away from the rest of your team.

But abstracting those services to be able to use two different cloud providers will highlight a bigger issue: How do you deal with the workings and limitations of each service? If we go back go our SNS vs Pub/Sub example you have to deal with the fact that AWS SNS has a much lower payload size than GCP Pub/Sub. Sure you are Multi Cloud after spending days or weeks abstracting both services. But now you're missing on the best features of each service.

So I can just ignore other cloud providers and forget about Multi Cloud?

I didn't say you should ignore other cloud providers. I'm all-in on AWS and think they provide are currently the best choice. But other providers like Google and Microsoft are doing really cool and amazing stuff too.

The most important thing is to take full advantage of the Cloud. Employ Cloud-Native Development, use those managed services that will save you thousands of euros and accelerate your development. Build software that has the right abstractions so you can avoid having AWS specialists and have good developers instead.

Spending time and resources to build a Multi Cloud architecture will result in having an inefficient architecture that took much longer to implement. Competitors who didn't bother with Multi Cloud will have launched new features much sooner and at a lower cost.