A discussion I have seen many companies have is if they should be single-cloud (using only one cloud company) or multi-cloud (using more than one cloud company). The three major Cloud Service Providers (CSPs) that companies use for nearly all use cases are Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP). First, here are the benefits of being multi-cloud:
- Improved ability to meet SLA’s: One CSP could have reduced latency or better HA/DR than another
- Reduced cost: The same service may be cheaper at another CSP or the price is the same but has more features or performance
- Reduced lock-in: Some companies don’t like the idea of using one CSP because they are “putting all their eggs in one basket”. Or they fear the CSP they are using might become a competitor to their business, which has happened with AWS
- Capacity issues: If one CSP has capacity issues, you can lean on the other CSP for the capacity you need
- Missing features/products: There may be certain features or products that one CSP has that another does not, and you would like to use those. Or a way to hedge your bet that one cloud company will introduce a new product/feature that the other does not have. Think best-in-class services or best-of-breed. Also, it could be a CSP supports a government cloud in a certain region and the others do not
- Data sovereignty: One CSP may have a cloud region that another does not. For example, if you are using MongoDB in Azure, but Azure does not have a region in Taiwan, you can use MongoDB in AWS for Taiwan. This could be very important for government or regulatory reasons
But there are plenty of reasons that multi-cloud may not be a good idea:
- Performance: All these clouds are not designed to work together so moving data and compute back and forth between clouds is typically very slow and clunky. Plus all the CSPs have egress charges when moving data between clouds
- Increasing the skillset: Your company will need to understand two or more clouds, greatly increasing your costs
- Reduced interoperability: Each CSP is of course only thinking about working with its own components, so having a product from one CSP work with a product from a different CSP could prove to be very challenging
- Switching costs: Moving data and applications from one CSP to another and launching another product could be very costly, especially if you have to re-engineer applications to support multiple clouds. And there is usually no simple migration capability between CSPs. Also think about if you have purchased a bigger pipeline to the Internet, such as ExpressRoute with Azure, you would have to make the same purchase at the other CSP
- Management overhead: Now you will have an additional CSP to manage and will have to create additional policies, standards, and procedures. Another increase in cost
- Administrative complexity: You will now have two very different types of security between CSPs that you have to get to work together, two places to add/delete/update users, two places to monitor, billing from multiple CSPs, just to name a few things. Yet another increase in cost
- Least common denominator: If you want to make it easy to move from one cloud to another, you won’t be able to use features in one CSP that others don’t have. In particular, you will have to use Infrastructure as a Service (IaaS) offerings instead of Platform as a Service (PaaS) which takes away a major benefit of being on the cloud. This is a big opportunity cost as you can no longer use the higher value services that each CSP offers
- Exposure: Having data in multiple clouds increases the exposure of your data, and instead of increasing your security expertise in one cloud you are splitting it between multiple clouds
I did not put as a benefit that being multi-could means you can negotiate a better deal from a CSP because you have put them in a compete situation. That is more of a myth. With CSPs, the more you use, the bigger discounts you get. For enterprise license agreements (ELA), the CSPs give you higher discounts based on how much consumption you can commit on their cloud. They call such commitment-based discounts different names such as pre-commit discounts, commercial pricing discounts, or volume-based discounts. Then add in tier-based pricing, reserved instance pricing (or committed usage discounts), and sustained usage discounts, and you can see you will save more sticking with just one CSP.
And one thing to note: having two cloud providers isn’t going to save you from an outage. The CSPs have specifically designed their networks so that an outage at one region doesn’t impact other regions. So your disaster recovery solution should be to failover to another region within the same CSP, not a failover to another CSP.
Finally, going with just one CSP could allow for partnership benefits, such as EY has with Microsoft: EY and Microsoft announce expansion of collaboration to drive a US$15b growth opportunity and technology innovation across industries – Stories.
I believe that the multi-cloud approach will prove to be short lived and in time most companies will choose one CSP and stick with them so that they can go deeper and leverage the services and ecosystem fully as applications modernize to take full advantage of that cloud’s PaaS and SaaS. This is especially true now that all three CSPs have very few unique features or products anymore.
Some companies will settle on a couple of clouds as they are big enough to invest the time and people to go deep on both, and that makes sense if the clouds offer something different that is beneficial to the workload, but be advised only to do so if you go in deeply with both and take advantage of the PaaS services that each offers.
More info:
The Why and How of Multi-Cloud Adoption
The Advantages of Accepting Lock-In From Your Cloud Provider
Why multicloud management is a mess
Is A Single Cloud Provider a Single Point of Failure?
The myths (and realities) of cost savings with multicloud
What are your architectural drivers for adopting multi-cloud?
Advantages of Going All-In On a Platform Versus Diversifying
The post Single-cloud versus Multi-cloud first appeared on James Serra's Blog.
