All multi-cloud environments share one trait in common: They combine resources hosted in one public cloud with resources hosted in at least one other public cloud.
But there are various ways to go about building a multi-cloud environment, each with different pros and cons. This article discusses three distinct approaches to setting up a multi-cloud architecture.
The what and why of multi-cloud architectures
Historically, most organizations that used the cloud used just one cloud. However, faced with increasing pressure to build cloud environments that are resilient, cost-effective and agile, more and more businesses have pivoted in recent years to multi-cloud architectures, meaning architectures that include two or more public clouds.
(Hybrid cloud environments, which combine private infrastructure with public cloud infrastructure, are also sometimes considered a form of multi cloud, although it’s more common to define hybrid cloud as a distinct type of architecture.)
By enabling nimble cloud strategies that let teams spread workloads across more than one cloud environment, a multi-cloud approach offers several important benefits:
- Reliability: Multi cloud can increase workload reliability and performance. A failure or performance issue in one cloud won’t disrupt your entire workload if the workload is spread across clouds.
- Cost-effectiveness: Multi-cloud strategies give businesses the flexibility to pick and choose from among as many cloud service offerings as possible. In turn, they make it easier to build the most cost-effective cloud strategy.
- Reduced lock-in risks: When you use multiple clouds, you are less likely to become highly dependent on a single cloud provider’s tooling or services.
Ways to build a multi-cloud architecture
Today, most multi-cloud deployment strategies are based around one of the following approaches.
Unintegrated public clouds
The simplest approach to multi cloud – but also the least sophisticated and the hardest to manage – is one in which a business deploys applications and/or data on different public clouds and manages each cloud independently. There may be some loose integrations between the clouds, such as the use of network peering to improve connectivity between them or the use of platforms like JFrog Artifactory that can share artifacts across multiple clouds. But in general, each cloud operates as its own entity, with nothing resembling a centralized or consistent management plane.
This strategy provides the basic benefits of multi cloud: It lets you spread your workloads across more than one cloud to improve reliability, it gives you the flexibility to choose from many cloud services and it reduces your dependence on a single cloud vendor’s tooling. It’s also easy to set up because you don’t need to build complex integrations.
The major downside to this approach is that management is more difficult. You will have to juggle two separate stacks of cloud administration tools – one for each of your clouds. So, although this strategy reduces initial setup complexity, it results in more management effort over the long term.
In addition, it is typically difficult to cost-optimize a cloud environment that spans two or more unintegrated clouds. Strategies that optimize cloud spend for one cloud may not apply to the other.
Many organizations adopt this approach as the first step in their journey toward multi cloud because it is simple. But the cost and management drawbacks encourage businesses to evolve their multi cloud strategies into more mature models over time.
Vendor-supplied multi-cloud integrations
A second approach to multi cloud is to use a hybrid or multi-cloud framework that is designed to integrate workloads spread across multiple clouds into an environment that can be managed via a single control plane. Most public cloud vendors offer some version of this type of framework; examples include Google Cloud’s Anthos and Azure Arc.
These platforms are relatively easy to deploy. They also simplify multi-cloud administration because your entire multi-cloud environment can be managed through a central platform.
The major downside to using one of these frameworks is that you end up depending on a multi-cloud platform developed by a specific vendor. Thus, you may face some lock-in risks. You are also limited to whichever management tooling the platform supports, and there may be costs associated with using the platform.
Kubernetes as a multi-cloud solution
A third multi-cloud strategy is to deploy and manage Kubernetes clusters in multiple clouds, but manage them through a single Kubernetes control plane. If you’re already familiar with Kubernetes, this is a relatively easy setup to deploy, because running Kubernetes across multiple clouds is not significantly more difficult than running Kubernetes in a single cloud.
The main benefit of this approach is that you can implement cost-saving optimizations for Kubernetes and apply them to any of the clouds you manage via Kubernetes.
You’ll also get the benefit of being able to manage all of your clouds via a central platform. In addition, depending on which Kubernetes distribution you use, you may not have to pay for the management platform. And because Kubernetes is open source, there isn’t a high lock-in risk to this approach.
The chief drawback of Kubernetes as a multi-cloud management platform is that it can be difficult to manage if you aren’t already a Kubernetes expert. Network configuration can be especially challenging because you’ll need a Kubernetes network plugin that supports multi cloud, and you may need to implement complex network configurations within each of your clouds to make the plugin work properly.