By all accounts, multicloud is the future. And for lots of companies, multicloud is already the present.
But multicloud is also a big buzzword. It’s not always clear what people even mean when they’re talking about, for example, multicloud deployments.
In this article, we’ll take a look at what multicloud, hybrid cloud, and intercloud really mean. We’ll also introduce a new term, single-workload multicloud, to refer to a specific type of multicloud deployment. Finally, we’ll dig into some of the key factors to consider when trying to choose which of these deployment methods is best for you.
What is multicloud?
The term multicloud is used to refer to any company, application, or service that uses more than one cloud computing service. It is also sometimes written multi-cloud or multi cloud.
Multicloud, in its most common usage, describes companies that have contracts with multiple public cloud providers (such as AWS, GCP, and Azure), and that is how we’ll use it for the remainder of this article. Intercloud and single-workload multicloud are related terms that describe more specific multicloud use cases, as we’ll discuss shortly.
It’s worth noting that in the real world, these terms are often muddled and used interchangeably. Particularly when a company is described as “multicloud,” it doesn’t actually tell us much about how their applications work, as the speaker might mean they’re running two wholly separate applications on two different clouds (which is relatively straightforward), or the speaker might mean they’re running a single workload across multiple clouds (which is significantly more complex).
What is hybrid cloud?
The term hybrid cloud is used to refer to any company, application, or service that uses a combination of one or more public clouds as well as on-premises infrastructure.
This type of deployment is common among companies that are in the process of transitioning to cloud infrastructure, but still wish to take advantage of the on-prem hardware and expertise that they already have.
What is intercloud?
The term intercloud is used to refer to any application that uses a combination of one or more clouds. The key difference between multicloud and intercloud is that while a company with multiple applications, one running on one cloud and another running on a different cloud, could be described as multicloud, only a company that’s running a single application across multiple clouds could be described as intercloud.
Intercloud is a relatively new term, and it’s not yet widely used or universally understood, even in tech spaces. Many people would simply describe this type of deployment as a specific flavor of multicloud, and there’s nothing wrong with that! However, in some situations it is useful to have a more specific term like intercloud that tells us something about the company’s actual application architecture.
What is single-workload multicloud?
The term single-workload multicloud is used to refer to any single application service or workload that is run across multiple clouds. For example, if an application’s database was deployed in a single cluster spanning multiple clouds, that would be considered an example of single-workload multicloud.
We’ll be honest here: single-workload multicloud is not an established term (yet). It’s not one that you’re likely to hear often as these use cases are still quite limited, especially outside of global enterprises.
However, the term has proved useful to us here at Cockroach Labs from time to time, as our database can be deployed as a single cluster that spans multiple public clouds. For services like ours, it can be useful to have a term that differentiates between that, intercloud (where each individual application service or workload is still limited to a single cloud) and multicloud (where whole applications are often still limited to a single cloud).
What is “cloud agnostic”?
A related term that sometimes comes up in multicloud discussions, cloud agnostic is used to describe a product, tool, or service that can run on any of the major public clouds.
For example, Cockroach Labs is a multicloud company. We operate our managed service, CockroachDB dedicated, on AWS, GCP, and Azure, meaning that we work with all three clouds. CockroachDB, the product. is cloud-agnostic, meaning that it can be run on any of those clouds. One customer may choose to use CockroachDB on AWS, another may prefer to run it on GCP, or on-prem. That’s cloud agnostic.
(In the case of CockroachDB specifically, you can also run a single database cluster across multiple clouds to leverage a single-workload multicloud deployment, but that isn’t the case with all cloud agnostic tools. In general, the term “cloud agnostic” means you can run it on the cloud of your choice, but not that it’ll necessarily run across multiple clouds.
Putting it all together: multicloud vs hybrid cloud vs intercloud vs single-workload multicloud
To sum everything up, let’s look at four hypothetical companies and try to describe them with the term that fits each best:
Company 1 has two separate applications. One of them runs on AWS, and the other is run on Azure.
Company 2 has one or more applications. Some of its services are run on AWS, while others run on its own infrastructure in the company’s on-prem datacenter.
Company 3 has one application. The application’s business logic and primary databases operate on AWS, but its analytics workloads are run on GCP.
Company 4 has one application. Its primary database is run in a single database cluster that spans both AWS and Azure.
Given the above descriptions and the definitions we’ve discussed:
Company 1 is best described as multicloud.
Company 2 is best described as hybrid cloud.
Company 3 is best described as intercloud.
Company 4 is best described as single-workload multicloud.
(That said, as we’ve already mentioned, in the real world these terms aren’t always used precisely. All four companies might well be described as “multicloud” depending on who’s talking).
Which cloud deployment makes sense for you?
Now that we’ve disambiguated multicloud, hybrid cloud, intercloud, and single-workload multicloud, let’s take a quick look at some of the factors to consider when trying to choose which of these approaches makes the most sense for your own use case.
There are no easy answers here, unfortunately, but these decisions typically must weigh factors such as…
Risk mitigation
Broadly, there are risks inherent in being tied to a single cloud. Chief among them: migrating to a different cloud is time-consuming and challenging. If you’re locked into a single cloud and they decide to raise their prices (or a competitor decides to lower theirs), you won’t be able to react to that quickly. Being multicloud, at a minimum, means that you have in-house experience and tooling that should make migrating to the other cloud easier, allowing you to be more flexible and respond more quickly to threats such as price hikes and service disruptions.
Single-workload multicloud, while technically complex, can also be a tactic for mitigating risk when it comes to tier zero workloads that simply must remain available. Even on the biggest public clouds, full-region outages are not unheard of – GCP had one earlier this year, for example – and having your critical workloads run across multiple clouds can mitigate the impact of those kinds of outages when they occur.
Negotiation leverage
Particularly at the enterprise level, cloud pricing is negotiated, and companies have stronger leverage when they’re already set up on multiple clouds, for several reasons.
First, the fact that they have the in-house expertise and tooling to work on a second cloud makes the potential threat of them migrating applications, services, or workloads from the first cloud more realistic. Migrations are always a pain, and cloud providers know that companies won’t do it lightly. But even so, the threat of leaving AWS (for example) is more plausible if you’ve already got an application up and running on Azure.
Second, being set up on a second cloud means you already have an active partnership with them and vice versa. They know they’ve won some of your workloads, and they’d like to win more, which incentivizes them to make you a compelling offer… which you can then take to the first cloud to ask them to match or beat. (This is theoretically possible without actually being multicloud, of course, but in practice it’s often quicker when your company already has an established relationship with the second cloud provider.)
Customer demands
B2B SaaS companies are often capable of multicloud, intercloud, or even single-workload multicloud because different customers have different cloud requirements.
For example, CockroachDB dedicated can run on AWS, GCP, or Azure, and CockroachDB is capable of hybrid cloud and single-workload multicloud deployments too. Why? Because our customers have specific cloud requirements.
Major banks and finance companies, for example, sometimes require single-workload multicloud and hybrid cloud for regulatory compliance and/or resilience. To serve those customers as a DBaaS provider, CockroachDB must be capable of multicloud.
Similarly, single-cloud customers often have specific requirements. Azure shops will want to use SaaS products that can be run on Azure. Amazon competitors often want to avoid AWS. As a SaaS company if you’re offering a service that’s likely to be run in the cloud, you will lose customers if you aren’t multicloud.
RELATED
Which cloud is right for you? Get our free benchmarking report
Regulatory compliance
Depending upon your company, industry, and the markets in which you operate, existing or likely future regulations may influence your decisions when it comes to multicloud. Increasingly, regulators are considering stronger technical regulations for key industries like finance. The EU’s new DORA regulations, for example, mandate that companies embrace an operational resilience strategy that, for many, means moving towards multicloud or even single-workload multicloud to decrease concentration risk (among other reasons).
Elsewhere, regulators seem to be moving in a similar direction, particularly in the context of critical or “sensitive” industries such as finance, defense, and healthcare. Forward-thinking companies have already seen the writing on the wall, and begun moving towards multicloud options before it’s legally required.
Existing infrastructure
Do you already have your own on-prem datacenters? Depending on the specifics of your situation, it can actually be cheaper to use these in tandem with a public cloud by embracing a hybrid cloud model, even if your ultimate aim is to be fully cloud or multicloud.
Leveraging existing infra for a hybrid cloud setup is also a very common step for companies that aren’t yet ready to transition to fully cloud-based, or want to get a better understanding of the costs and performance of cloud deployments before fully committing.
Technical complexity
Adding additional clouds to your tech stack increases complexity. In the context of a multicloud company where one application runs on one cloud and a different application runs on another, this impact is limited, although it does mean that you’ll need internal expertise in working with both.
Things get more complicated with intercloud and single-workload multicloud deployments, though. Networking between the public clouds, for example, can be a significant technical challenge, and not one that the clouds are particularly inclined to help with!
Moreover, while all of the clouds tend to offer similar services, there are small differences and “gotchas” that can be difficult to anticipate in advance. Even understanding your costs becomes more complicated when you’re running across multiple clouds and have to pull and join consumption and cost data from multiple sources.
Particularly when considering intercloud and single-workload multicloud deployments, talent and expertise must be considered. Do you have – or can you hire – the talent to deal with these issues? And speaking of hiring…
Talent and hiring
The technical challenges inherent in intercloud and single-workload multicloud deployments do have an upside, though: those types of meaty, interesting, complex problems are just the kind of thing that top engineers enjoy working on.
Having a product that leverages an intercloud or single-workload multicloud deployment may thus make it easier to attract and win the best engineering talent.
Overall cost
Taken at face value, any kind of multicloud deployment looks like it costs more than a single-cloud deployment. You’ve got to hire talent and build for two clouds rather than one. With hybrid cloud, intercloud, and single-workload multicloud deployments you will often also need to worry about additional costs such as cloud egress charges.
However, it’s important to run the numbers, because multicloud can actually be cheaper depending on the specifics of your use case. In addition to the general negotiation leverage that being multicloud can offer, some companies are able to save money through cloud arbitrage, moving services around to follow the lowest costs for specific use cases across cloud providers.
And while a complex deployment like a single-workload multicloud database won’t be cheaper than deploying that same instance onto just one cloud, if that cloud has an outage that affects your product, what is the cost of that? Even relatively short outages can cost businesses millions in lost business, not to mention the reputation damage that comes from users trying to use your service and finding that it doesn’t work. A single-workload multicloud deployment might cost you more in the short run but save you millions in the long run if it shields you from significant outages.
Tooling
Does your existing tech stack work across multiple clouds? Does cloud agnostic tooling exist to replace any proprietary cloud tools you’re using?
At this point, there are third-party cloud agnostic tools available for use at nearly every level of the tech stack, and a move towards multicloud or even something more complex such as intercloud becomes easier when you’re already leveraging these tools rather than trying to optimize two different tools on two different clouds for performance and compatibility.
Lift and shift or net-new?
Trying to lift-and-shift an existing application to make it intercloud (for example) can actually be more complex than trying to build a net-new application that’s designed to be multicloud from the ground up. If your time and resources are limited and if you’re not already using cloud agnostic tooling, consider whether it makes more sense to try to convert your current application to multicloud or to move towards replacing it with a new application that’s built to be multicloud from day one.
Long story short: whether and how your company should move towards multicloud is a complex question that should be considered carefully with the specifics of your budget, use cases, long-term goals, and all of the factors above in mind.
