Why Multi-Cloud doesn't mean what you think it means
How we got to “the age of Multi-Cloud”
For years now we’ve been hearing, mostly from CMP (Cloud Management Platform) and traditional Data Center Hardware/Software Vendors, that the Multi Cloud means:
- I can “move” my workloads between different clouds, based on current price, performance etc.
- I’m being smart and avoiding Lock-in, by adding an “agnostic layer of technologies” on top of my Multi-Cloud space.
- I’m mitigating a risk of global Cloud Provider failure.
Sounds awesome…
Is this the reality, though?
I’ll be honest, when I started working with Cloud, I was hearing the above arguments so much, that I started believing them. Then I started building multi-cloud environments with different customers around Europe, and the entire experience completely changed my mind.
I’ll tell you about the 5 issues I’ve been able to identify all my customers were facing while adopting the Multi-Cloud Strategy.
Multi-Cloud Issue 1: Lock-In
The sad truth is - you can’t avoid the lock in, accept that. You’re either locked in with your Cloud Provider, or a CMP (or whichever multi-cloud product/s) vendor, or your small engineering team, who built and is operating the damn beast.
If you’re doing a lock in - do it right! Relax, and think about Reliability and Cost. I’m sure you can calculate your SLAs, SLOs, and price of the app, depending on where you’re deploying it.
IMHO - Serverless always wins, both SLA and Cost. And Serverless is always exclusively built on cloud proprietary services. So if your SLA really makes you go multi-cloud - consider doing Serverless on both Clouds. Sure, it’s more engineering hours, but you’ll save so much on cloud infrastructure…
Multi-Cloud Issue 2: Complexity
If you use a Cloud, like AWS or GCP, you also get a set of tools for deployment, monitoring, auditing etc.
If you go Multi-Cloud, you need:
- Architects who know every cloud perfectly.
- Engineers who can use tools in each of the clouds.
- Tools on the “abstraction layer”, because a tool from one cloud doesn’t work on the another. Yes, you will need to buy tools that support multi-cloud. This is both complex, and very, very expensive.
Multi-Cloud Issue 3: Data Gravity
This is a simple one: where is your data? If you’re planning to consume a Data Lake in AWS using a Service in Google Cloud - you should really go over the traffic costs in the cloud. Rule of thumb: it will ALWAYS cost you to get data OUT of your Cloud. This all sums up a pretty “decent” cost.
If someone is building a frontend is in AWS, and consuming a Database in their data center - they better have a damn good reason.
Multi-Cloud Issue 4: Cost
Serverless is super cheap. Multi-Cloud doesn’t do serverless (at least not the way most people understand Multi-Cloud). It does VMs, or Kubernetes, or similar… basically - to do Multi-Cloud you will be consuming the most expensive services in each Cloud.
Multi-Cloud Issue 5: Did you really read that Compliance?
Compliance is something Data Center Hardware vendors mention a lot when trying to make a point that Hybrid Cloud or Multi Cloud is here to stay.
I did this exercise with so many of my customers. They throw the argument of compliance at me, and I propose reading the document together. Compliance and Regulation will almost never define that your data has to be in multiple different clouds, or a data center. You might be tied to a geographical location, so if your data needs to stay in Spain, and AWS still doesn’t have a Region in Spain till 2023 - you’ll just have to keep your data somewhere else in the meantime.
Conclusion: Multi-Cloud - YES PLEASE! But MY way!
True differentiators in the Cloud are elasticity and having everything as a managed service. In my humble opinion, instead of ignoring Serverless, which is THE amazing thing of the cloud, and engineering your own layer on top, stop and think about your priorities:
- Reliability.
- User Experience when using my service.
- Infrastructure cost.
And pretty soon, it will be obvious. You SHOULD use Multi-Cloud, BUT:
- Build different apps (or Blue/Green of an app) in different clouds, where the Services that cloud provider offers best fit your user case.
- Maybe use a particular service a particular cloud offers as part of your app. If the data traffic is small, it can make a lot of sense to use the best of all worlds.
- Please do serverless whenever you can. It’s how you really get the best of Cloud. You’ll thank me later…