[ Guides ]
Best practices for multi-cloud
Save time and money by approaching multi-cloud the right way.
Get your copy of the reportThere’s a lot of hype around multi-cloud, but that doesn’t mean adopting a multi-cloud architecture is right for everyone.
Particularly in more complex deployments such as intercloud (in which a single application is run across multiple clouds) and single-workload multi-cloud (in which a single workload runs across multiple clouds), multi-cloud gets technically challenging and expensive fast.
So, what are the best reasons to adopt multi-cloud? We asked 300 experts in technical leadership roles (CTO, chief architect, etc.) at companies across the US, Europe, and Germany. We also interviewed our own engineers, who are on the ground building our own multi-cloud application (CockroachDB is available on AWS, GCP, and Azure) and helping our customers succeed with building their own multi-cloud applications.
Our full results are now available in our new State of Multi-Cloud 2024 report, which covers everything from adoption trends and patterns to best practices for success when building a multi-cloud application. But in this article, we’ll take a closer look at one of the questions the report aims to answer: what are the best reasons to consider multi-cloud?
Good reasons to leverage multi-cloud
In responses to our survey, experts across the US, UK, and Germany broadly agreed on the best reasons for considering multi-cloud adoption:
Our in-depth interviews with engineering experts also echoed these findings.
Broadly, the lesson is clear: the best reasons for adopting multi-cloud relate to solving business problems rather than technical problems. But let’s dig a bit deeper into some of the most commonly-cited reasons to adopt multi-cloud:
For regulatory compliance
Regulatory compliance was the most-cited reason in our survey overall, in large part because of the trend towards regulating operational resilience in critical industries such as finance. The EU’s DORA regulations, for example, will take effect in January of 2025. The laws don’t explicitly require companies to adopt multi-cloud, but they do require that companies make an effort to mitigate risks, and many companies have made multi-cloud a part of their response to DORA due to the inherent risks associated with being concentrated on a single cloud:
This risk may be particularly acute in smaller countries with data sovereignty laws. In the UK, for example, some major cloud providers only offer a single region. In the event of a regional outage, any application concentrated exclusively on one of those clouds and also subject to data sovereignty laws would go offline, as it cannot fail over to a cloud region that is outside of the UK.
Check out our 2024 multi-cloud webinar with Erol Kavas, Cloud Architect and Director at PwC.
For avoiding vendor lock-in
Avoiding vendor lock-in – or to put it a different way, maintaining cloud flexibility – was also a top reason experts cited for going multi-cloud.
By and large, most companies are not interested in the hassles associated with a major cloud migration. But they are also aware of the risks of being wholly reliant on a single cloud provider, and thus at the mercy of their pricing whims. Companies that are completely satisfied with their primary cloud provider may still consider some form of multi-cloud to give them more flexibility – in the event they ever do find it necessary to migrate, they’ll already have the skills and expertise required to make things work on the new cloud.
(Making your application work on a different cloud, it should be noted, is often far more difficult than it might appear. While the major public cloud providers offer broadly “squint-equivalent” services, the devil is in the details, and small differences between them can and often do lead to major problems when trying to build software that can work on both – grab a copy of the report to read about some of these issues in much more detail.)
For meeting customer requirements
B2B companies often choose to adopt a multi-cloud architecture because it allows them to meet customers where they are, and serve more customers than they otherwise might.
CockroachDB itself is a good example of this. We built the database to be able to run on AWS, GCP, and Azure (in addition to private clouds and on-prem) because different customers have different requirements. Some customers are all-in on AWS and require that their database run on AWS, too. Other customers consider Amazon a competitor and cannot put any of their infrastructure on AWS.
For B2B SaaS providers, meeting customers where they are often means meeting them on their preferred cloud or combination of clouds. And that, in turn, means that the SaaS product itself must be multi-cloud.
For leverage in price negotiations
38% of our survey respondents cited negotiation leverage as a potential reason for adopting multi-cloud. In theory, having a presence on multiple clouds allows a company to more credibly threaten to walk away during price negotiations with cloud providers. This can be particularly effective in regions where one cloud provider dominates and its competitors are aggressively trying to expand, offering low prices to attempt to tempt the incumbent’s customers away.
In our in-depth interviews, some experts expressed skepticism about this negotiation tactic. To be sure, cloud migrations tend to be complex and expensive, and cloud providers know that companies will need a truly compelling reason to move. However, if a company that’s primarily an AWS shop (for example) also has a presence and some in-house expertise with GCP and GCP is attempting to expand in its region by aggressively pricing its offerings below the AWS equivalents, that can give the company some real leverage in their price negotiations with AWS.
For empowering your teams
Hiring and team empowerment were also top-cited reasons that companies consider multi-cloud adoption. There are two primary forms this takes:
First, some companies opt to support multiple clouds so that they can empower specific engineering teams to choose the cloud provider and cloud products that best suit their specific use case. While the three major cloud providers are mostly “squint-equivalent,” some are better than others for specific use cases, and allowing teams to leverage this can improve overall application performance (as well as team morale).
Second, engineers are often interested in complex problems and adding valuable skills to their resumes, and working at a multi-cloud company can offer the potential for both. Some experts told us that the fact that they were building a multi-cloud application helped when it came to trying to attract the best engineering talent.
Case-specific reasons to go multi-cloud
Beyond those five reasons, there are additional good reasons to consider multi-cloud if your use case matches some specific parameters. This is discussed in more detail in the report, but we will briefly mention a couple of them here.
For resilience
Generally speaking, resilience isn’t a great reason to go multi-cloud, as it is possible to meet many common availability goals through single-cloud multi-region deployments, which allow you to avoid the high egress costs associated with moving data from one cloud provider to another (which is typically 4-5X as expensive as moving data from one region to another on the same cloud).
However, in some specific cases, such as limited cloud region availability within a country, or extremely high availability requirements, a multi-cloud deployment can make sense. Multi-cloud is expensive, after all, but so is downtime. For critical, this-cannot-go-down applications, the availability offered by multi-cloud may be worth the substantial costs associated with it.
For cost savings
For some specific use cases such as ephemeral spot-instance game servers, operating across multiple clouds can allow you to chase the best pricing in near real time, spinning up servers on whatever cloud is most affordable in that region at the moment. This approach doesn’t work for workloads that require much in the way of persistent data, since moving data from one cloud to another is highly expensive, but in the context of something like a video game server, only a tiny amount of data (usually player performance statistics) has to persist, making this kind of cloud pricing arbitrage possible in some cases.
