Discussion of multi cloud has increased over last few months. As with many Cloud topics, when people say multi cloud, there are many meanings of it. Lets examine:
1. Multi Cloud with workloads moving between different cloud providers
Based on some dynamic characteristics ( demand, pricing etc ), you will move the workloads between cloud providers. In theory, you may do cloud “bursting” etc ( LOL )
2.Multi Cloud where you are consuming services from different cloud providers
In this scenario, you use the best of the breed. An example could be leveraging Google Vision APIs for an app running on AWS.
3. Multi Cloud with clean separation of workloads between different cloud providers
In this scenario, some workloads may be running on a different cloud provider. For example, you may run all your tier 1 workloads on AWS, while tier 2 workloads on GCP.
I consider scenario #1 to be a pipe dream and vendor marketing.
I understand scenario #2 and as long as you keep the separation clean , it could work.
Scenario #3 works, if you account for network latency and increased data costs.
So, what are the pros and cons of multi-Cloud approach? Below are some from my perspective:
- Less vendor dependency
Using many cloud providers reduces the dependence on a single vendor and allow you to optimize your costs. You may decide to run on spot instances for workloads designed to be fault tolerant and save money, while running legacy workloads on reserved instances. This may also give you peace of mind that your business is not at the mercy of a single vendor.
- Negotiation power
If your Cloud spend is large, this may allow you to negotiate better pricing on your Cloud costs. Every cloud provider negotiates when your Cloud spend crosses over a million dollars annually. Having the ability to run workloads on many cloud providers is a valuable tool in your negotiation toolkit. Perhaps, they will give you a discount if you commit to exclusive usage.
- Increased Ops burden
Using multiple cloud providers increases burden on your ops team. You now have to automate for different cloud providers, account for their specifics etc. You need to build ops expertise across different clouds.
- Harder to move talent between workloads
Its hard enough to find talent that knows one cloud provider well. Its even more harder to find talent that can work across multiple cloud providers.
- Increased complexity of your deployment targets
If you are running similar workloads on different clouds, you have to ensure that you accounted for all these deployment targets. Would your Lambda functions translate nicely to Azure functions? Would your application logs to AWS CloudWatch work in Azure the same way with an equivalent service?
- Have to use least common denominator of capabilities
If you want to move between cloud providers at a whim, you need to use least common denominator between cloud providers. Examples: Till recently, if you needed good functioning ML models, you had to use Google. If you wanted event driven functions, you were limited to AWS.
- Slow rate of adopting new innovations
Being multi Cloud puts a burden and slows down your rate of innovation. You want to make sure that whatever you are building works across all cloud providers and similar capabilities exist.
From my perspective, the cons outweigh the pros of trying to be multi Cloud for a mid sized to large organizations. But, if you are a basic user of Cloud and just rent VMs and may be use some DB services, you can go multi Cloud. But, know that it imposes constrains on your ability to adopt new Cloud services faster.
The multi Cloud debate so much reminds me of the best of breed vs integrated stack debate of the early 2000s. ( Remember BlueStack, RedStack ? ). I think there is no right or wrong answer, but for current period, my recommendation is to commit to a single Cloud provider and go all in. This may change in future.