What is Multi-Cloud Infrastructure? Benefits, Best Practices

In this post, we will dig into the Multi-Cloud infrastructure world. What does it look like when I want to provide my technology in more than one cloud provider? What does it mean when I need to provision and manage production infrastructure in more than one cloud provider?

Multi-Cloud Infrastructure is a term used to describe a data center environment that uses multiple cloud computing services. A multi-cloud setup can increase flexibility and redundancy and improve disaster recovery capabilities.

There is the classic, avoiding vendor lock-in. If you are a retail business running your infrastructure in AWS, you may want a plan for how to replicate that infrastructure to GCP or Azure. So if Amazon decides to eat into your space you can switch to a different cloud provider that isn’t a competitor. 

Or there is the more expensive, less likely, and a bit out there reasoning. AWS goes down. Like, completely offline kind of down. Think the recent Facebook outage kind of a down. In this scenario, you want a “hot-hot” failover to another cloud meaning your entire infrastructure is not only replicated in another provider, but it can be ready to accept traffic at a moment’s notice. A very, very, very hard problem to solve. Not to mention very expensive.

That said, there are reasons and use cases between these two extremes. A simple one is you want to offer your technology to clients that only use one cloud or another. Customers want to use your technology, via your platform as a service (PaaS). But they want to be able to say, “provision your technology in this specific cloud provider”.

This is a very real use case that bleeds into the multi-cloud conversation. When multi-cloud is thrown around, the first two use cases are often thought of. But this third use case is actually much more likely. With the right tools and processes, it’s also a lot more practical. 

In this post, we will dig into this world. What does it look like when I want to provide my technology in more than one cloud provider? What does it mean when I need to provision and manage production infrastructure in more than one cloud provider?

It depends on the problem you are in the business of solving. If a major cloud provider dipping their toes into your industry is a major threat, maybe it makes sense. Or if complete fault tolerance is necessary for your business, replicating your infrastructure in a “hot-hot” fashion to multiple cloud providers might be of interest to you.

It all comes down to your business, the product you are offering, and the expectations of your users. Those three factors will play into whether multi-cloud is of importance or not.

But, at a high level, what are the real benefits of multi-cloud infrastructure?

1. Support different use cases and customer demands.

Customers like to have choices. Not so many choices that it’s overwhelming, but enough to feel flexibility. This is very prevalent if you are building any kind of platform or platform as a service offering. Your users will eventually ask if you can run your technology in AWS, GCP, or Azure. 

Why? Maybe they view Amazon as a competitor and want to avoid directly or indirectly giving money to their competition via AWS. Perhaps they have credits in GCP that would make using your technology over there more cost-effective. It’s possible their entire engineering team is only familiar with Azure. So they don’t want to introduce a learning curve by adding another provider.

So, if you provide your technology in more than one cloud provider, you can solve these problems for your customer.

2. Cloud providers iterate rapidly.

Cloud providers are in constant competition with one another. They are in a steady state of developing new services and offerings. They are in the business of helping customers (you) in solving your problems more efficiently. Competition is good for you, a multi-cloud thinker.

You can iterate on your own product or offering to leverage the latest cloud development that improves your services. With multi-cloud, you leverage that development in whatever cloud provider introduces it first. Are you going to be able to introduce that new feature or performance boost in all cloud providers? No, but one out of three isn’t bad until the other providers catch up.

We now know some pros, cons, and common misconceptions surrounding multi-cloud infrastructure. Now it’s worth chatting about some high-level best practices. These practices can be leveraged to make multi-cloud possible, easier to work with, implement, or all of the above.

1. Choose the right tool and set up processes.

First, it’s all about choosing good tooling. The cloud automation tools you choose to manage your infrastructure are going to make or break your multi-cloud adventure. We could even say that multi-cloud is impossible if you’re not using some kind of infrastructure as code.

It’s important to choose an IaC tool that supports multi-cloud. If you are all in on AWS and you represent all your infrastructure in Cloudformation, you are going to have a very difficult transition to multi-cloud. So, choosing the right tools that keep the door open to multi-cloud is critical.

Beyond choosing good tools, you need processes that make them required. This means if you represent all infrastructure as code, do not allow for manual creation or modification. Developers shouldn’t be able to create or change infrastructure in the console. Changes made by hand cause anomalies in your production environment. Anomalies that are not represented in code.

2. Modularize the core components in IaC.

Second, modularize the core components of your architecture in your IaC. Say your technology runs in a Kubernetes cluster provided by AWS. You configure `cert-manager` to be deployed to that cluster so you can do SSL/TLS to deployments. With Terraform, you should have a module that represents all the resources for the Kubernetes cluster. Then a second module for `cert-manager` that gets installed into the cluster.  

If you have a clear module system in your IaC, multi-cloud becomes a bit easier. Why? Because you know what modules need to be recreated to support another cloud provider. When you want to run this workload in GCP, you need to create an equivalent Kubernetes module. But you should be able to plug in the `cert-manager` module with no need to rework it, as it just needs a Kubernetes cluster. Read more: How to develop Kubernetes multi-cloud multi-cluster strategy.

3. Make architecture decisions that facilitate multi-cloud.

Finally, make architecture decisions that facilitate multi-cloud. This is rather obvious when you stop and think about it, but it is often overlooked. If your architecture relies on a specific service in a specific cloud provider that operates in a particular way, it may not be possible to use another cloud provider.

The core cloud providers all have similar services. For example, AWS has Lambda, GCP has Cloud Functions, and Azure has Azure Functions. So if your architecture needs some function as a service offering, you should be alright, at a high level. You may need specific features or performance from a given cloud provider service. These are not always similar and can even be very different.

So, as a best practice, you should aim to make your architectures as generic as possible. This makes it easier to port them across providers. Containerization is a great tool to think about that can make this possible.

Here are some good tools and processes for supporting infrastructure in multiple clouds.

1. Terraform, Pulumi, etc for declaring your multi-cloud infrastructure in code. Choosing a cloud provider-specific tool is still better than no IaC tool, but it doesn’t facilitate multi-cloud. Read more: What is Terraform
2. Continuous integration and deployment for your IaC. Spacelift is a fantastic tool for this. It allows you to automate, audit, secure, and continuously deliver your infrastructure.
3. Containers provide a cross-cloud packaging and deployment mechanism. You can use Docker or one of the other many tools out there for building containers like `buildah` or `podman`. Containers unlock the ability to have a single way to package your application and deploy it to any given cloud provider.
4. Okta or some kind of central identity solution. No one should be able to access cloud provider consoles via logins. Instead, it’s better if they come in through some kind of SSO provider like Okta. This makes it easier to map your developers to roles or authentication mechanisms in different cloud providers.

Multi-cloud is not a small project. It requires careful planning, and a lot of such planning from the beginning of your product or technology. If multi-cloud is something you hope to tack on two years down the road, it likely won’t work.

It requires avoiding architectures, tools, and processes that lock you into a specific cloud provider. So if multi-cloud infrastructure is something you may need in the future, keep it in mind when you make decisions around all these things.

To make the process easier, you can consider using Spacelift. It works with cloud-agnostic IaC technologies like Terraform and Pulumi, as well as cloud-specific IaC features like AWS CloudFormation and Azure ARM templates. No matter which IaC technology is used, Spacelift provides a common interface to manage the automated provisioning of multiple stacks in multiple cloud platforms