The Myth of the Multi-Cloud Strategy

Note: Everything reported here are my personal thoughts based on my experience. This means it does not represent Microsoft in any statement.

Introduction

In my work life, more and more often I see companies thinking at a multi-cloud strategy, sometimes even with 3-4 Cloud Platforms in their vision.

The principal reasons of this can be grouped in the following statements:

• Avoid Vendor Lock-In (Procurement): Companies think that leveraging only one Cloud provider can significantly reduce negotiation power against the vendor during contract renewal. The possibility to push competition at contractual time can give them the ability negotiate nicer concessions for the new contract.
• Better Efficiency (Technical Teams): Companies think they can pick-up, for every single project, the best cloud platform that fit they need for those particular services in terms of costs and performance and move them around if these conditions change.
• Better Legal and Governance Compliant (Legal and Complaint Departments): Based on the old way of how they implemented Disaster Recovery Strategies for On-Prem, the idea to "not put all the eggs in one basket" can prevent pitfalls and stay compliant with all regulations.

If you look at them as single points, they definitely make sense. But if you start to look at them globally at company level, you will see that having a Multi-Cloud Strategy could be more expensive, inefficient and in some way more dangerous that a single-cloud one.

To be clear, you can have and implement a multi-cloud strategy but doesn't mean you should: it will come with significative overhead in terms of costs, culture, skills and complexity that can easily kill any business case you have internally and also any competitivity in the market.

Let's see why I think that and what could be a good alternative to it.

Avoid Vendor Lock-In

let's start with a fact: Cloud providers always benchmark their services with the competitors in term of costs and features.

Regarding costs, it means you will never find huge differences in market prices for the services. For "huge" I mean something that could cover the migration cost from one provider to another and, even if the migration costs could be absorbed as concession from the new provider, it's really difficult to quantify and avoid the risks of such migration (especially in operations post-migration).

Also, even if you get incredible concessions for the first contract, the renewal you will be again in the same situation. Why? Because Cloud providers always negotiate on the grow (your future forecast of consumption) not on the baseline (your current consumption) and, unless you are jumping every renewal from one to another (good luck with that...), the discussion will be the same of the renewal with your previous provider.

Regarding features, Cloud world is extremely dynamic and don't have a fix product lifecycle as we had for On-Prem products: The agility could provider got from the "centralized" infrastructure implementation permits them to deploy new features in weeks instead of years (Remember the SQL and Windows 3 years story?)

And again, they are watching each other's! So, if one of the cloud providers deploy an interesting new feature required by many customers, it's quite sure that this feature will appear in few week/months to the other ones in a flavor or another.

Better Efficiency

I can partially agree that there are service implementations that are better on one cloud provider and "less performant", "less feature-rich" or "less user-friendly" (reporting here some of the most common remarks I got) on the others.

The problem here is that only the performance efficiency is took in consideration and not the global efficiency.

Let's give an example: you are deploying in 3 different cloud providers - one because is "better" for VMs, one because is "better" for Kubernetes and another one because is "better" for Data and AI (try to name them if you can ;) )

For sure you are cherry-picking the most performant services here and there but what are paying in exchange?

• Your Dev Team have to learn and optimize on 3 clouds instead of one: That inevitably means they wouldn't be utilizing any of the clouds as well as they do one unless you have expert for each of them doubling/triplicating the costs. Please don't say container will fix this! This is just NOT TRUE! Not all applications are good candidate for containers and even if is good, your container needs to be optimized for the platform you are running it on otherwise why are you doing cherry-picking for performance? :)
• Your Ops Team need to deal (monitoring, patching, upgrading, securing) and handle failures on 3 clouds instead of one and, maybe, they need to maintain 3 different flavors of the same pipeline in your CI/CD. Again, probably you need to double/triplicate your costs.
• Your Infra Team has to build on top of 3 different clouds (with not exactly one-to-one matching of the service limitations, features, costs) and even if they can take advantages from a strict IaC strategy they need to learn and maintain 3 different languages or using a cross platform one (Terraform) with 2 main pain points: first, it will be common in schema but not in the content (it means that you need anyway to write/test/deploy/maintain it 3 times). Second, it will not be immediately ready for new services as soon as they come out. Again, costs up!
• Your Network Team will need to multiply the "hubs" required for interconnect all the cloud providers and also taking in consideration that data transfer "infra-cloud" is usually more expensive than the "intra-cloud". Try to guess? exactly! more costs!

This configuration will actually pulverize any business case you have in terms of ROI and/or price to market for your solutions.

Better Legal and Governance Compliant

Especially if you are working in a highly regulated industry (Health, FinTech just to names some...) Legal and Compliance requirements are critical and maybe you need to certify multiple environments running on different cloud providers.

Also, governance and policies on different cloud vendors leads inevitably to either in security risks if the governance is too lax or in a decrease of efficiency if the governance it's too strict.

There are solutions that can alleviate this and that support multi-cloud (Azure ARC is one of them and, probably, the most complete at the moment) but they don't cover 100% of the digital estate (especially related to particular PaaS solutions specific to single providers) and you need to pay and maintain that solution (again costs).

Also Disaster Recovery in different clouds is definitely an expensive, complex and unfriendly exercise: Many, if not all, Cloud Regions (for all major providers) are "splitted" in different datacenters close to each other (in Microsoft we call them availability zones) and paired in to a different region within the same country or a closer one (in Microsoft we call that Paired Region). So, if you are using the correct configuration of the services (governance!), you have your data replicated in 6 different physical locations with an usually acceptable RTO/RPO and also you get automation for that, something that you have to build and maintain yourself in a multi-cloud DR strategy.

Conclusions

In my opinion, a Multi-Cloud Strategy is, in general, not a convenient idea.

In some cases, it's required for legal reasons (like data sovereign - even if I will suggest you consider a Hybrid approach with your current cloud provider) and only because the law you are following is probably not updated/too conservative for the lack of knowledge of the legislator about how the cloud works (the DR story is usually one of the blocker..)

What is a good option for me it's a Multi-Cloud Tactic and it's not just a semantic difference.

Let me explain it:

You should have one principal cloud provider where your company could invest in terms of skills, governance, security, innovation to become a top-class utilizer and to squeeze the maximum value from every penny you are spending. This should be used on 95% of your projects and all the tools should be aligned and fully optimized to support it.

Which one you should choose it really depends on you, but it should be the one that is first-class for your most common architecture blueprints and that matches your internal skills but also "good enough" in the other areas of interest that you would like to explore so you don't pay that much in performance gap for future programs.

And you should have one or more tactic ones for the remaining 5% where you run specific solutions that need to be on that specific platform because they are extremely more competitive there. These applications should also be implemented and operated by an external team of (real) experts that use that cloud provider as their primary focus.

The rule should be that additional costs of the outsourcing should be more than compensated from the added value the "not-standard" cloud platform is providing in that specific case. So always benchmark it with your primary cloud provider to avoid jeopardize your digital estate for no reason.

Does it mean that one you choose one provider is forever?

Not at all, you can change cloud provider whenever you want, but the shift in terms of culture, skills, technology is significant and should not be underestimated: this "Transformation" is probably only slightly less "disruptive" than the first you had already from on-prem to cloud so needs to be correctly evaluated, planned and executed. You can take advantages from the first contract from the new provider that probably will be happily provide huge amount of money to help you in the Cloud-To-Cloud journey.

Probably in the future, when the cloud maturity of your company (and of the people working on it) will be higher and also the third- party solutions will evolve and will be able to add an abstraction layer on top of the Cloud providers that can really standardize the implementations and operations, the situation will change but, at the moment, Multi-Cloud is as expensive exercise that is not giving back the right added value.