Kyle is a Software Engineer with 12+ years of experience, he specializes in infrastructure as code tooling & best practices, serverless computing, and container orchestration.

All post by Kyle Galbraith - DevOps & Cloud Expert

Kyle Galbraith

Author title

OpenTofu is now part of the Linux Foundation 🎉

Title category

Get all the latest content on Infrastructure as Code, DevOps, Spacelift features & news directly to your inbox!

Level up your IaC knowledge. Stay up to date with educational devops guides & news in infrastructure as code, cloud & more!

Managing Infrastructure at Scale | Spacelift Blog

applepodcasts

spotify

missionctrl

Welcome to missionCTRL, a show dedicated to exploring the frontiers of modern DevOps. Listen (or watch) as we sit down with the practitioners who are pushing the boundaries of development

What does infrastructure as code look like when you are supporting multiple cloud providers?

General | Spacelift Blog

General

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&#8217;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 advantages and disadvantages of multi-cloud?

<h3>1. Support different use cases and customer demands.</h3>
Customers like to have choices. Not so many choices that it&#8217;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.
<h3>2. Cloud providers iterate rapidly.</h3>
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.

<ul>
<li><a href="https://spacelift.io/blog/ci-cd-tools" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Top Most Useful CI/CD Tools for 2023&quot;}" data-sheets-userformat="{&quot;2&quot;:4737,&quot;3&quot;:{&quot;1&quot;:0},&quot;10&quot;:2,&quot;12&quot;:0,&quot;15&quot;:&quot;Arial&quot;}">Top Most Useful CI/CD Tools for 2023</a></li>
<li><a href="https://spacelift.io/blog/drift-detection" target="_blank" rel="noopener">Fixing Infrastructure Drift with IaC Tools</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;10 Ways to Improve Your Infrastructure as Code&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">10 Ways to Improve Your Infrastructure as Code</a></li>
</ul>

We now know some of the pros, cons, and common misconceptions surrounding multi-cloud infrastructure. Now it’s worth chatting about some high-level best practices. These are practices that can be leveraged to make multi-cloud possible, easier to work with, implement, or all of the above.
<h3>1. Choose the right tool and set up processes.</h3>
First, it’s all about choosing good tooling. The 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 <a href="https://spacelift.io/blog/terraform-vs-cloudformation" target="_blank" rel="noopener">Cloudformation</a>, 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.
<h3>2. Modularize the core components in IaC.</h3>
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 <a href="https://docs.spacelift.io/vendors/terraform/module-registry#modules-in-practice" target="_blank" rel="noopener">module system in your IaC</a>, 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.
<h3>3. Make architecture decisions that facilitate multi-cloud.</h3>
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.
<ol>
<li>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: <a href="https://spacelift.io/blog/what-is-terraform" target="_blank" rel="noopener">What is Terraform</a></li>
<li>Continuous integration and deployment for your IaC. <a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">Spacelift</a> is a fantastic tool for this. It allows you to automate, audit, secure, and continuously deliver your infrastructure.</li>
<li>Containers provide a cross-cloud packaging and deployment mechanism. You can use <a href="https://www.docker.com/" target="_blank" rel="nofollow noopener">Docker</a> 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.</li>
<li><a href="https://www.okta.com/" target="_blank" rel="nofollow noopener">Okta</a> or some kind of central identity solution. No one should be able to access cloud provider consoles via logins. Instead, it&#8217;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.</li>
</ol>

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 <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a>. 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

Spacelift allows you to automate, audit, secure, and continuously deliver your infrastructure.  It helps overcome common state management issues and adds several must-have features for infrastructure management.

How Spacelift Can Improve Your Infrastructure as Code

Business Benefits of Infrastructure as Code

5 Ways to Manage Terraform at Scale - Best Practices

What is multi-cloud infrastructure? See best practices, advantages, and misconceptions. Learn what tools to use for infrastructure in multiple clouds.

27-multi-cloud-strategies

What is Multi-Cloud Infrastructure? Benefits, Best Practices

Why should business care about infrastructure as code

Infrastructure as code (IaC) is being used in companies small and large, technical and non-technical. The days of configuring your infrastructure by hand are moving behind us. More and more infrastructure is being represented as code. Whether it is HCL with Terraform, TypeScript with AWS CDK, or Python with Pulumi. 
This transition to infrastructure as code is fast-paced and changing at a rapid clip. So it begs the question, why is infrastructure as code becoming so important? But also, why should a business or a product manager invest their developer’s time in establishing it?

Investing in solid infrastructure as code practices is no small investment. It has its own learning curve and the steepness of the curve varies across different <a href="https://spacelift.io/blog/infrastructure-as-code#infrastructure-as-code-tooling" target="_blank" rel="noopener">IaC tools</a>. So if a team is going to invest this time, what are the benefits?
The benefits of cloud computing are well known at this point. The ability to scale out and in your compute resources automatically. Cost savings from no longer needing to pay for the overprovisioned hardware running in your closet. Pushing massive security processes to the underlying cloud provider. All these things are benefits of cloud computing.
But what are the tradeoffs? There are many. The one that is most relevant to infrastructure as code is complexity. Running production-level workloads in the cloud is complex. It’s not a problem if you are running a single web application on an EC2 instance behind a load balancer. But it’s quite a bit different when you are running a web application, a database, a Kubernetes cluster, and some serverless functions to support all the services of your application.
That problem is only exacerbated when you need to run many environments. Think about your development, staging, and production environments. You have to provision and maintain all that infrastructure. Doing that manually is a massive burden and time commitment.
This complexity is why infrastructure as code is critical. Depending on your chosen tool you can represent all that infrastructure as a single module in code. Then when you want another environment you add another instance of that module with your new environment name. All that work to create the module never has to be repeated again, like DRY for your infrastructure.
But infrastructure as code is important for another reason. Visibility.
With infrastructure as code, everyone has visibility into what the current configuration is. Why? Because it’s represented in code and committed to a source code repository. Anyone who has access to the code can see what the current configuration is. Changes to the infrastructure configuration go through a pull request review. With pull requests, everyone can see what is changing and why.
There is a large list of reasons <a href="https://spacelift.io/blog/infrastructure-as-code#benefits-of-infrastructure-as-code" target="_blank" rel="noopener">why IaC is important</a>. But the two most important that make huge differences from day one are better complexity management and increased visibility into infrastructure configuration.

All those reasons infrastructure as code is important ring true for engineering teams. But a Product Manager might not see those as benefits to what they are trying to deliver, solutions for their users. It’s a bit of the classic engineering and product tug of war that is natural. But with infrastructure as code, the benefits of investing that time and resources can seem opaque to someone who is always thinking about the end-users of the product, not the underlying infrastructure.
So we must take a look at what the benefits of infrastructure as code would be for someone in a product role. More generally, these are benefits the entire organization can realize:
<h3>1. Decreased risk</h3>
Provisioning all your infrastructure by hand is risky. It requires manual work that is error-prone. It may require a single person to do. That person could leave the company, taking all that knowledge with them. Infrastructure as code minimizes both of these risks. By representing infrastructure as reproducible blocks of code we are far less error-prone. Infrastructure as code lives in a source code repository. Its history and changes are visible to everyone on the team. 
<h3>2. Stable &amp; consistent environments for faster iterations</h3>
When environments have to be manually configured or modified it slows down product development. This is especially true if the product wants to change its architecture to better serve its users. With infrastructure as code environments are stable, consistent, and easily modifiable. They live in code alongside the product, so when we want to change one we can change the other at the same time. This harmony means that new features can be developed for the product faster. There is less overhead to managing a given environment.
<h3>3. Cost optimization</h3>
When all resources are represented in code you can see what is running and what shouldn&#8217;t be. Optimizing cost maintains product profit margins. Those optimizations become much easier with infrastructure as code.
<h3>4. Self-documenting</h3>
There is a philosophy in software development that says good code is easy to read. It often doesn’t need extensive comments because it’s clear what it’s doing. The idea is that a new developer should be able to come in, read the code, and understand the logic that is happening. With infrastructure as code, it is self-documenting like any other code. This can benefit the product by making it easier to add more people to the team. With self-documenting code, you can reduce the time it takes for a new developer to onboard into the team.

<ul>
<li><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Common Infrastructure Challenges and How to Solve Them&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Common Infrastructure Challenges and How to Solve Them</a></li>
<li><a href="https://spacelift.io/blog/drift-detection" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Infrastructure Drift Detection and How to Fix It With IaC Tools&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Infrastructure Drift Detection and How to Fix It With IaC Tools</a></li>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;10 Ways to Improve Your Infrastructure as Code&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">10 Ways to Improve Your Infrastructure as Code</a></li>
</ul>

<a href="https://spacelift.io/" target="_blank" rel="noopener">Spacelift</a> is a platform to manage infrastructure provisioning workflows which also eases the developer experience to a vast extent. <span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Spacelift allows you to automate, audit, secure, and continuously deliver your infrastructure. It helps overcome common state management issues and adds several must-have features for infrastructure management.&quot;}" data-sheets-userformat="{&quot;2&quot;:769,&quot;3&quot;:{&quot;1&quot;:0},&quot;11&quot;:4,&quot;12&quot;:0}">It allows you to automate, audit, secure, and continuously deliver your infrastructure. It helps overcome common state management issues and adds several must-have features for infrastructure management.
It is a very powerful platform as it works with cloud-agnostic IaC technologies like Terraform, OpenTofu, 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.

Infrastructure as code is a game-changer for companies large and small. The benefits of it are often expressed as engineering benefits. But the benefits of it are felt across the entire business from product to finance. 
It’s not a silver bullet. It requires investment. But when that investment is made the benefits are almost immediate. Faster product iterations, decreased risk, optimized costs, and simpler onboarding are all benefits that can be felt in the engineering team, but also within the product team. An investment into a healthier infrastructure process using infrastructure as code can pay dividends for the entire life of the product or company.

Spacelift is a flexible orchestration solution for IaC development. It delivers enhanced collaboration, automation and controls to simplify and accelerate the provisioning of cloud based infrastructures.

Alternative to Atlantis – Spacelift

Infrastructure as code is a game-changer for companies large and small. In this article, we describe the benefits of Infrastructure as code from the engineering perspective and across the entire business from product to finance. 

Kyle Galbraith

What is Multi-Cloud Infrastructure? Benefits, Best Practices

Get the newsletter

Recent posts

Business Benefits of Infrastructure as Code