General | Spacelift Blog

Author title

Using generic CI/CD tools for your IaC automation? 🤖⚙️

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

Transform your IaC management to scale
securely, efficiently, and productively
into the future.

Blog

What Are Terraform Modules and How to Use Them: Tutorial

Terraform Functions, Expressions, Loops (Examples)

Managing Terraform State - Best Practices & Examples

Terraform For Loop - Expression Overview with Examples

What is Terraform? What is it Used For, How it Works

44 Ansible Best Practices to Follow [Tips & Tricks]

How to Stop and Remove Docker Containers

How to Create a CI/CD Pipeline with Docker [Tutorial]

CI/CD Pipeline : Everything You Need To Know

Kubernetes CI/CD Pipelines - 7 Best Practices and Tools

How to Deploy Infrastructure in CI/CD Using Terraform (Pipeline)

Terraform with Azure DevOps CI/CD Pipelines - Tutorial

Terragrunt Tutorial - Getting Started & Examples

Pulumi Pricing – Editions Overview 2024

73 Most Useful DevOps Tools to Use in 2024

Top 10 Terraform Enterprise Alternatives for 2024

Terraform Cloud/Enterprise Pricing - Tiers Overview 2024

16 Most Useful Infrastructure as Code (IaC) Tools for 2024

Terraform Cheat Sheet - 23 Terraform CLI Commands & Examples

ebook-global-banner

ebook global banner

Product overview

How it works

Integrations

Product

Solutions

Standardize and control infrastructure provisioning and configuration

cicd

CICD

cicd-2

Infrastructure Governance

Implement and automate secure, collaborative workflows

team

Team

team-2

Collaboration

Make it easy for developers to provision and configure with a single workflow

speed-2

Speed

speed-3

Developer Velocity

Scale your infrastructure safely and efficiently with an end-to-end workflow

productivity

Productivity

productivity-2

Infrastructure at Scale

Use cases

Financial

Technology

Industries

Request a meeting

Enjoy an action-packed day at AWS Summit London 2024, where the latest in cloud innovation comes to life.

ebook-pic

Practitioner’s Guide to Scaling IaC

Check out the Practitioner's Guide to Scaling IaC

Docs

Pricing

Resources

Learn more about Spacelift and infrastructure best practices

blog

blog-2

partners

Partners

partners-2

events

Events

events-2

Insights and quick guides to get you started

cheatsheets

Cheatsheets

cheatsheets-3

Ebooks & Cheatsheets

users

Users

users-2

Case studies

33-what-makes-spacelift-secure

What Makes Spacelift Secure

About Us

Contact Us

About

cheatsheets-2

Test

See more

Test webinar name

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 Is Infrastructure as Code? Examples, Best Practices & Tools

General

Jack Roper

Infrastructure-as-code (IaC) is a very important concept to understand in the DevOps world today. It has become almost ubiquitous across the industry and is absolutely key to modern engineering roles.
In this post, I will explain what IaC is, what its benefits are, some of the tooling options available, and point out some best practices along the way. I will then look at some code examples for each tool to compare and contrast.
You will learn:
<ol>
<li><a href="https://spacelift.io/blog/infrastructure-as-code#what-is-infrastructure-as-code-iac" rel="">What Is Infrastructure as Code (IaC)</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-as-code#benefits-of-infrastructure-as-code">Benefits of Infrastructure as Code</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-as-code#challenges-and-limitations-with-iac">Challenges and Limitations with IaC</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-as-code#why-should-i-store-my-infrastructure-as-code-in-a-version-control-system-vcs">Why Should I Store My Infrastructure as Code in a Version Control System (VCS)?</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-as-code#declarative-vs-imperative-approaches">Declarative vs. Imperative Approaches</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-as-code#infrastructure-as-code-tooling">Infrastructure as Code Tooling</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-as-code#infrastructure-as-code-examples">Infrastructure as Code Examples</a></li>
</ol>

Put in the simplest terms, using code, you define the infrastructure that needs to be deployed in a descriptive model. Similar to code for applications, the code for the infrastructure becomes part of the project and is stored inside your version control system (or VCS).
For example, consider that you have developed a web application. That web application needs to be hosted on infrastructure somewhere to be consumed. Using IaC you could define things like where the infrastructure is deployed to, such as a public cloud provider like Microsoft Azure, Amazon AWS, or Google Cloud, and what type of service your web application will run on, such as an Azure web app, or an AWS S3 Storage account. Further to this, you can then define the settings required for the web app, which might include things like how much server compute power is required (in terms of CPU and memory), how the networking is secured, and how the domain name for your app will be exposed, to name a few among many other considerations.

IaC solves many common problems with provisioning Infrastructure.
<ul class="">
<li id="597c" class="mp mq io kf b kg kh kj kk km mr kq ms ku mt ky mu mv mw mx gj" data-selectable-paragraph="">New environments or infrastructure can be provisioned easily from your IaC configuration code. Infrastructure deployments with IaC are repeatable.</li>
<li id="2ed8" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">Manually configured environments are difficult to scale. With environments provisioned using IaC, they can be deployed and scaled rapidly.</li>
<li id="1fa7" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">If you want to make changes to the existing infrastructure that has been deployed with IaC, this can be done in code, and the changes will be tracked.</li>
<li id="e257" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">When IaC is used with a declarative tool (it describes the state you want your environment to look like), you can detect and correct environment drift. If a part of the infrastructure is modified manually outside of the code, it can be brought back in line with the desired state on the next run.</li>
<li id="42dd" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">Changes can be applied multiple times without changing the result beyond the initial application. This is known as idempotence.</li>
<li id="e195" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">Avoid manual configuration of environments which can typically introduce mistakes due to human error. With IaC, these can be avoided.</li>
<li id="449b" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">IaC is a means to achieve consistency across environments and infrastructure. The code can be reused.</li>
<li id="7a68" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">Infrastructure costs are lowered as the time to deploy and effort to manage, administer and maintain environments decrease.</li>
<li id="3dd7" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">IaC can be used in Continuous Integration / Continuous Deployment (or CI/CD) pipelines. The main benefit of doing this is to <a href="https://spacelift.io/blog/infrastructure-automation" target="_blank" rel="noopener">automate your Infrastructure deployments</a>.</li>
<li id="b7bc" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">DevOps teams can test applications in production-like environments early in the development cycle.</li>
<li id="9dd2" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">With your Infrastructure configuration code held in your version control system alongside your application source code, commonly in the same repository. Now everything can be held together.</li>
<li id="7002" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">Productivity will increase due to a combination of all the benefits of using IaC.</li>
<li id="f688" class="mp mq io kf b kg my kj mz km na kq nb ku nc ky mu mv mw mx gj" data-selectable-paragraph="">As the code is held in your version control system, it gains all the benefits of the VCS. More on that in the next section.</li>
</ul>

The adoption of IaC is not without its challenges.
Typically, traditional infrastructure or operations teams within organizations may not be familiar with version control systems, use of Git, or be comfortable using tools for code editing such as visual studio code.
Further to this, there is certainly a learning curve when it comes to the adoption of new technology within an organization. Training will be required and time will be needed to develop the appropriate skills.
Skills in IaC and DevOps are currently highly sought after in the industry and so therefore it may be difficult to hire staff with these skills.
The journey to managing your environments using IaC will typically start with a small deployment of new resources to your chosen cloud platform, and from there once adoption within the organization grows, more of your infrastructure can start to be deployed and managed in code. Eventually, when your organization is mature and comfortable with the principles and operation of your chosen IaC systems and tooling, existing resources can be brought under IaC control.

Without diving too deeply into the benefits of using a VCS in this article, we will summarise them here as storing your IaC in a VCS automatically gives you a raft of additional benefits.
In summary, a VCS enables developers and organizations to work more efficiently in improving the quality of their product while recording and evaluating a detailed history of their improvements that will lead to a successful end product. In short, using a VCS enables governance, versioning, and increases collaboration.
1. Efficiency
As configuration files are amended incrementally with changes, testing becomes easier as rollback to previous versions is possible. New features can be built up over time.
2. Tracking &amp; Versioning
Track who made the change, and in which version of the file. Comments can be added to each code change (or commit).
3. Collaboration
Multiple people can work on the configuration files at the same time using branching. Changes can be merged together using pull requests.
4. Governance &amp; Compliance
Tracking changes automatically gives you a powerful audit trail, enabling risk management.
5. Management
A management overview becomes possible through being aware of the author of the configuration, how long it took to make changes, the timeline and its impact.
6. Reduces Duplication
Multiple and out-of-date configuration files are reduced.
7. Backup
Users will typically clone the repository their configuration code is held in and work on it locally. The code then exists locally and in the VCS. The VCS itself is also backed up.

There are 2 approaches to the templates used when writing IaC configuration files. Different tools use different approaches, which are listed in the next section.
Declarative — you define the desired state of the final solution.
The tool or automation platform determines how the goal is reached, the step-by-step executions are handled by the tool and hidden from the user. Declarative tools are the most popular and most dominant in the IaC space. They are most useful when changes or updates need to be made to your solution.
Declarative tools are idempotent because you are defining the required state of the solution. Idempotency refers to a process that can be executed multiple times with the same result.
Imperative — you define the steps to execute in order to reach the desired solution.
An imperative approach allows you to build up multiple layers of commands to reach the end goal. Imperative tools give you more control over how the goal is reached. These tools are most useful when you need to deploy and not update or change the solution in the future.
Imperative approaches may not lead to idempotency, the end goal may be different depending on the starting point, as a series of steps form the process. Consider a process with 10 steps, for example, starting from step 1 would lead to a different result compared to starting with step 6.

<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/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Improve Your Infrastructure as Code using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Improve Your Infrastructure as Code using Terraform</a></li>
<li><a href="https://spacelift.io/blog/drift-detection" target="_blank" rel="noopener">Fixing Infrastructure Drift with IaC Tools</a></li>
</ul>

So you’ve decided to pursue IaC due to the myriad of benefits it enables. Now you need to decide which tool to use! This will depend on a number of factors, including your engineering capability and current use of cloud platforms.
You should also consider the use of a Continuous Integration / Continuous Delivery (CI/CD) platform and the tools that it supports before deciding. The most flexible platforms, such as <a class="au lo" href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a>, support multiple tools, including Terraform, Ansible, Pulumi, and CloudFormation. For example, with Spacelift, you can set up Terraform Stacks to provision required infrastructure (like an ECS/EKS cluster with all its dependencies) and then connect that to a CloudFormation Stack which then transactionally deploys your services there using <a href="https://docs.spacelift.io/concepts/policy/trigger-policy" target="_blank" rel="noopener">trigger policies</a> and the Spacelift provider <a href="https://registry.terraform.io/providers/spacelift-io/spacelift/latest/docs/resources/run" target="_blank" rel="nofollow noopener">run resources</a> for workflow orchestration and <a href="https://docs.spacelift.io/concepts/configuration/context#remote-state-alternative-terraform-specific" target="_blank" rel="noopener">Contexts</a> to export Terraform outputs as CloudFormation input parameters.
First, we will outline three cloud-agnostic options, Terraform, OpenTofu and Pulumi, before moving on to the Microsoft Azure cloud-specific ARM templates and Bicep. Lastly, we will briefly discuss other options for AWS, CloudFormation, and CDK, as well as other tools such as Ansible, Chef, Salt, and Puppet.
<h3>Terraform</h3>

iac1

Terraform logo

<a href="https://spacelift.io/blog/what-is-terraform" target="_blank" rel="noopener">Terraform</a> takes the declarative approach. It uses its own language called Hashicorp Configuration Language (HCL), which is considered by most as very easy to pick up and is very human-readable. HCL is based on Go.
Terraform can be used with almost any cloud provider, as well as on-premise infrastructure through its provider mechanism, of which there are thousands available. It is for this reason that many choose Terraform over other options. If you want to use the same language and formatting to configure infrastructure across multiple cloud platforms and infrastructure, it is a natural choice.
In my opinion, even if you only want to use it for one cloud platform (e.g., Microsoft Azure), it is still the best option, due mainly to the maturity of the language and its supporting ecosystem.
Terraform maintains a state file. The state file describes the existing state of the infrastructure and allows Terraform to query, build, maintain, and change the infrastructure as defined in your configuration files. Maintaining the state file introduces challenges around its security, but many solutions exist to the problem.
Dependency mapping between resources is done in the background automatically by Terraform and is largely hidden from the user, but can be controlled if required. Dependency mapping refers to the order resources are created in. Consider the creation of a virtual machine, first, you must have a VNET, subnet, disk, and key vault for disk encryption in place before it can be created successfully. Terraform makes sure resources are created in the correct order. If these need to be manually manipulated, the <code class="ng nh ni nj nk b">depends_on</code> met-argument can be utilized in the configuration to achieve this.
Terraform has a raft of great features, including allowing you to deploy to different environments using workspaces, and the ability to run plans to show what will change without making any alterations to name a couple.
Terraform does have a slight delay in terms of the features it supports. For example, when a new feature or service is released in Azure, this capability must be added to the <code class="ng nh ni nj nk b">azurerm</code> provider by the team that maintains it before the feature will be able to be referenced using Terraform. However, the delay is usually very small and almost all features that are available to a user in the Azure portal and available through Terraform configuration language. If your team lives on the cutting edge and utilizes lots of preview services, this might be an issue. This is not always the case for all providers, as when it comes to the <code class="ng nh ni nj nk b">aws</code> Terraform provider, some new features have been implemented before the AWS native CloudFormation!
Learn more about how you can <a href="https://spacelift.io/blog/terraform-automation" target="_blank" rel="noopener">automate your infrastructure provisioning with Terraform</a>.
<h3>OpenTofu</h3>

opentofu-iac

opentofu iac

<a href="http://opentofu.org/" target="_blank" rel="noopener">OpenTofu</a> is an open-source version of Terraform that will expand on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6. OpenTofu retained all the features and functionalities that had made Terraform popular among developers, while also introducing improvements and enhancements. The project is part of the Linux Foundation, with the ultimate goal of joining the Cloud Native Computing Foundation (CNCF).
There are no differences between Terraform (versions prior to 1.5.6) and OpenTofu, but this will change as new versions emerge. Initially, it works exactly the same as Terraform, with OpenTofu being a drop-in replacement for it. OpenTofu is not going to have its own providers and modules, but it is going to use its own registry for them.
The community dictates the direction of OpenTofu, which will offer greater flexibility in the development of new features, considering what is important for the users. There are a couple of interesting feature requests already in the <a href="https://github.com/opentofu/opentofu">repository</a>, and other features are planned, such as support for OCI provider registries and state encryption.
OpenTofu works with your existing Terraform state file so you won’t have any issues when you are migrating to it. 
Contributing to OpenTofu can be easily done by checking the <a href="https://github.com/opentofu/opentofu/blob/main/CONTRIBUTING.md" target="_blank" rel="nofollow noopener">Contribution Guide</a>. The easiest way you can contribute is by opening an issue, and every major change will be done through an RFC.
OpenTofu is the future of the Terraform ecosystem and having a truly open-source project to support all your IaC needs is the main priority.
<h3>Pulumi</h3>

iac2

Pulumi logo

<a href="https://spacelift.io/blog/what-is-pulumi" target="_blank" rel="noopener">Pulumi</a> is another declarative IaC tool. Instead of having its own language, it allows teams to use an existing programming language, something which can be highly desirable if your team already has strong preferences or skills. Pulumi supports TypeScript, JavaScript, Python, Go, and C#.
Like Terraform, Pulumi also supports multiple clouds, infrastructure, and providers.
Note that any existing Terraform or ARM configuration files you have can be converted into Pulumi files.
Pulumi is harder for coding novices to get to grips with compared to Terraform or Bicep. If no prior coding skills exist within your team, it will take time to learn.
As Pulumi configuration files are coded with the programming language of your choice, this means you can use the same testing tools as you use for your main code, another major advantage.
<h3 id="e9c7" class="pw-post-body-paragraph kd ke io kf b kg kh jp ki kj kk js kl km kn ko kp kq kr ks kt ku kv kw kx ky ih gj">Microsoft Azure ARM Templates</h3>
ARM templates are the native templating option for all resources in Azure. ARM templates are written in JSON format.
Getting started using <a href="https://spacelift.io/blog/arm-template" target="_blank" rel="noopener">ARM templates</a> is easy as ARM templates can be downloaded for any existing resource straight from the Azure Portal and can be modified as needed. These templates can allow you to redeploy resources easily. Because ARM templates are the native option in Azure, they are well documented and supported by Microsoft. They can also be used for any resource in Azure from the day of release, an advantage over Terraform.
However, when writing ARM templates from scratch there is a lot of ‘boilerplate’ code that is required, something that tools like Terraform and Bicep extract away from the user, making the code easier to both read and write. JSON language is picky about formatting and can be a chore to learn. Because of the additional code required for ARM templates compared to other options, the configuration files can get very large, complex, and hard to follow, and any syntax errors can become tricky to troubleshoot. There is no concept of ‘state’ when using ARM templates, so any changes that are applied can be breaking. In addition to these disadvantages, there is no plan, or ‘dry-run’ option available when using ARM templates, making it difficult to confirm that what you are deploying will result in the desired outcome.
Read more about <a href="https://spacelift.io/blog/azure-infrastructure-as-code" target="_blank" rel="noopener">using Azure for Infrastructure as Code</a>.

iac3

Azure Bicep logo

Azure Bicep is a declarative abstraction language used to simplify .json ARM templates that are used to provision infrastructure in Azure. Bicep is a Domain-specific language (DSL), so if you want to use the same language across multiple clouds, this isn’t the option for you.
Bicep aims to take away some of the unnecessary .json boilerplating, leaving simpler, cleaner code, similar to Hashicorps HCL. You can use modules, something not really available with ARM templates, allowing you to simplify complex deployments. Bicep can query the state directly from Azure, so there is no need to manage a state file, which is a great advantage over Terraform.
Bicep is still in its relatively early days, having come to prominence in the last couple of years, and so the community around it is not as large as that of Terraform. However, Bicep is fully supported by Azure Support teams meaning you can raise a ticket through the Azure portal for Bicep-related issues, similar to how you would raise a ticket for any Azure resource problems you might encounter. In theory, anything you can do with ARM templates you can do with Azure Bicep (and more) although some limitations still exist during to the ongoing development of the tool.
Bicep is part of the Azure CLI. Note that you can convert existing ARM templates into bicep files. As an example running the command below in cloud shell will convert your .json ARM template into a .bicep file:

<h3 id="1b64" class="pw-post-body-paragraph kd ke io kf b kg kh jp ki kj kk js kl km kn ko kp kq kr ks kt ku kv kw kx ky ih gj">Amazon Web Services (AWS)</h3>
<a href="https://spacelift.io/blog/terraform-vs-cloudformation" target="_blank" rel="noopener">CloudFormation</a> is the native AWS IaC tool and takes the declarative approach. CloudFormation templates are written in JSON or YAML format. CloudFormation is a managed AWS service and will check the infrastructure it has provisioned to detect if it is maintaining the described state, no state management is required which is a benefit over Terraform. Similar to modules in Terraform, AWS uses a concept called ‘nested stacks’, which enables templates to be called from other templates. Note that interestingly it is possible to provision resources on other clouds or non-AWS resources using CloudFormation, as the custom resources feature enables this. However, this involves additional templating and is certainly not as easy as using Terraform. CloudFormation support is included in AWS support plans.
Similar to Pulumi but not cloud-agnostic, the AWS Cloud Development Kit (AWS CDK) is an open-source software development framework to define your cloud application resources using familiar programming languages. CDK would be generally considered as taking an imperative approach.
<h3 id="b150" class="pw-post-body-paragraph kd ke io kf b kg kh jp ki kj kk js kl km kn ko kp kq kr ks kt ku kv kw kx ky ih gj">Ansible, Salt, Chef, and Puppet</h3>
These are generally considered as configuration management as code tools, but can also be used to provision and manage infrastructure.
Puppet takes the declarative approach. Chef takes the imperative approach. <a href="https://spacelift.io/blog/ansible-vs-terraform" target="_blank" rel="noopener">Ansible</a> and Salt are mostly declarative but offer some support for imperative commands.
See a more detailed <a href="https://spacelift.io/blog/infrastructure-as-code-tools" target="_blank" rel="noopener">list of the most useful IaC deployment tools</a>.

In this section we will compare the code required to create a Storage account in Azure, using Terraform, Pulumi, Bicep and ARM templates. All four examples will create the same result in Azure, a storage account with a container called ‘logs’.
<h3 id="830d" class="pw-post-body-paragraph kd ke io kf b kg kh jp ki kj kk js kl km kn ko kp kq kr ks kt ku kv kw kx ky ih gj">Terraform</h3>
Notice how easy to read the HCL language is, making it arguably the most accessible to the beginner of the four compared options.

See a more detailed guide on <a href="https://spacelift.io/blog/terraform-infrastructure-as-code" target="_blank" rel="noopener">how to manage Infrastructure as Code (IaC) with Terraform</a>.

<h3 id="7418" class="pw-post-body-paragraph kd ke io kf b kg kh jp ki kj kk js kl km kn ko kp kq kr ks kt ku kv kw kx ky ih gj">Pulumi</h3>
The Pulumi example can be coded in many different programming languages, here I have shown the Python equivalent as it will be a commonly used and understood language across infrastructure teams. In Python, it actually comes in slightly shorter than the terraform equivalent but is harder to read for the beginner.

Existing Terraform <a href="https://www.pulumi.com/tf2pulumi/" target="_blank" rel="nofollow noopener">can be converted</a> to Pulumi files using tf2pulumi, a great resource that lets you view the code side-by-side and convert it to Typescript, Python, Go, or C#.
<h3 id="8c19" class="pw-post-body-paragraph kd ke io kf b kg kh jp ki kj kk js kl km kn ko kp kq kr ks kt ku kv kw kx ky ih gj">ARM Templates</h3>
The ARM template example is much more lengthy and verbose, highlighting the issues with ARM templates that Bicep aims to resolve.

[parameters('storageAccountName')]

[format('{0}/default/{1}', parameters('storageAccountName'), parameters('containerName'))]

<h3 id="2d17" class="pw-post-body-paragraph kd ke io kf b kg kh jp ki kj kk js kl km kn ko kp kq kr ks kt ku kv kw kx ky ih gj">Bicep</h3>
The Bicep example is much more concise are easier to read than the ARM equivalent, although not quite as short as the Terraform.

The Bicep playground is a great resource that allows you to <a href="https://docs.microsoft.com/en-us/azure/azure-resource-manager/bicep/compare-template-syntax/?WT.mc_id=modinfra-57552-apedward" target="_blank" rel="nofollow noopener">directly compare</a> ARM templates and Bicep configuration files. Use the ‘Sample Template’ button to select a template to compare side-by-side. You will notice that Bicep files are always shorter, remove the ARM boilerplating, and as a result are easier to use.

<a href="https://spacelift.io/blog/devops-automation-tools" target="_blank" rel="noopener">Automating your Infrastructure</a> using IaC can pay dividends, enabling your team to deliver more and be more agile, saving you time and money.
Selecting the correct IaC tooling for your team can be a daunting task as there are plenty of options available. Comparing the pros and cons of each, along with an evaluation of your requirements and available skill sets in your team, should give you a good starting point.
If you are just starting out with IaC, I would personally recommend looking at Terraform first as it is a highly sought-after skill in the industry today, and is the prevalent IaC tool. There are lots of learning materials available on the web and the community support is great.

<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}">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.

What is Multi-Cloud Infrastructure? Benefits, Best Practices

What is Platform Engineering? Role, Principles & Benefits

17 Cloud Cost Optimization Best Practices for 2024

Infrastructure as Code (IaC) isn’t a new notion, but it still causes confusion. In this article, you’ll learn what IaC is, its benefits, best practices and code examples.

6-infrastructure-as-code

Infrastructure as Code : Best Practices, Benefits & Examples

Want to level up your Terraform knowledge? Explore our tutorials and step-by-step guides written by Terraform experts. Learn Terraform best practices and solutions to the most difficult problems.

Terraform Guides and Tutorials | Spacelift Blog

Terraform

Tianchen Wu

Terraform is a well-known IaC tool from Hashicorp. Terragrunt is a thin wrapper of Terraform that provides extra tools for keeping your configurations DRY, working with multiple Terraform modules, and managing remote states. It is an open source project from Gruntwork, co-founded by Yevgeniy Brikman, author of Terraform up and running.
This article discusses common patterns in <a href="https://spacelift.io/blog/infrastructure-as-code" target="_blank" rel="noopener">Infrastructure as Code (IaC)</a> based on Terraform and Terragrunt examples and summarizes and highlights the design principle underlying good architecture.
We will present these patterns in an abstract way. Although the examples presented in this article use Terraform and <a href="https://spacelift.io/blog/terragrunt" target="_blank" rel="noopener">Terragrunt</a>, the main concepts apply to other popular IaC tools and platforms like <a href="https://spacelift.io/blog/what-is-pulumi" target="_blank" rel="noopener">Pulumi</a>, AWS CDK, CloudFormation, <a href="https://spacelift.io/blog/what-is-terraform-cloud" target="_blank" rel="noopener">Terraform Cloud</a>, <a href="https://spacelift.io/blog/alternative-to-atlantis" target="_blank" rel="noopener">Atlantis</a>, Spacelift, and <a href="https://spacelift.io/terraform-cloud-alternative" target="_blank" rel="noopener">Terraform Cloud alternatives</a>.
Note: New versions of Terraform are placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that expands on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6.
To put it simply, “managing collections of infrastructure resources” is an abstract concept. The technologies used to implement this concept include:
<ul>
<li style="font-weight: 400;" aria-level="1"><a href="https://spacelift.io/blog/terraform-workspaces" target="_blank" rel="noopener">Terraform workspace</a></li>
<li style="font-weight: 400;" aria-level="1"><a href="https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacks.html" target="_blank" rel="nofollow noopener">Cloudformation (nested) stack</a></li>
</ul>
Git branch (allows you to create two branches, one called workspace_1, the other workspace_2, then relate remote state to each of the branches, which is actually a neat trick.)

In short, to utilize IaC is to describe your infrastructure with code. Coding infrastructure in HCL (<a href="https://github.com/hashicorp/hcl" target="_blank" rel="nofollow noopener">Hashicorp Configuration Language</a>) with Terraform is just like coding with any other programming language, like Python or Java. Programming technologies such as linter, IDE, unittest, documentation, and CICD, are all applicable to IaC. Additionally, a project layout is crucial to defining a structure to organize your code, dependencies, configuration files, etc.
One common pattern of the project layout for IaC is much like the following:

image1-3

common pattern of the project layout for IaC

The basic principle is to:
<ul>
<li style="font-weight: 400;" aria-level="1">Separate the process of IaC into two phases: development and deployment.</li>
<li style="font-weight: 400;" aria-level="1">Separate the deployment environments into prod, qa, and stage, for example.</li>
<li style="font-weight: 400;" aria-level="1">Separate the cloud architecture into components according to projects, types of infrastructure, etc. Each component can be stored in a single “gigantic” repository or multiple “micro” repositories (see Pattern: Mono-repo vs Multi-repo).</li>
</ul>

The process of IaC usually consists of two phases: development and deployment.
In the development phase, one writes code to describe and configure the desired infrastructure. In the deployment phase, the written infrastructure code is applied.
The advantages of separation:
<ul>
<li style="font-weight: 400;" aria-level="1">Separation of Concern: developers who write IaC do not need to know the details of the deployment, and can work or test on a new version of the code without influencing the actual deployed infrastructure.</li>
<li style="font-weight: 400;" aria-level="1">Flexibility: a well-designed IaC codebase is modularized and parameterized. The same code snippet can be reused and deployed under different use cases in different environments with customized parameters.</li>
</ul>

<ul>
<li><a href="https://spacelift.io/blog/terraform-in-ci-cd" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;How to Deploy your Infrastructure in CI/CD using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Deploy your Infrastructure in CI/CD using Terraform</a></li>
<li><a href="https://spacelift.io/blog/5-ways-to-manage-terraform-at-scale" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Managing Terraform at Scale - Best Practices&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Managing Terraform at Scale – Best Practices</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;How to Improve Your Infrastructure as Code using Terraform&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">How to Improve Your Infrastructure as Code using Terraform</a></li>
</ul>

Imagine you have an AWS cloud architecture for web services, including different AWS services like ECS, RDS, S3, IAM, SSM, Secret Manager, Cloudwatch, Cloudfront and so on. One option is to pack all of the components into a single Terraform remote state (main.tf). This is fine for quick and dirty prototyping, but not recommended for production.
Always cut your cloud architecture into meaningful components such as:
<ul>
<li style="font-weight: 400;" aria-level="1">Stateful components like database, filesystem, or S3.</li>
<li style="font-weight: 400;" aria-level="1">Stateless components like lambda, ECS, or API Gateway.</li>
</ul>
You can also cut it based on projects or functional areas (e.g. frontend, backend, data warehouse).
The advantages of separation:
<ol>
<li style="font-weight: 400;" aria-level="1">Avoids scanning the whole architecture if a change needs to be made only locally to one resource. One can enter the component folder which includes that resource, make changes there, and apply them. Scanning a fat cloud account can be time consuming on a large amount of cloud resources, even causing unnecessary API throttling.</li>
<li style="font-weight: 400;" aria-level="1">Avoids unnecessary touches on databases or other crucial infrastructure to prevent accidental destructive operations.</li>
<li style="font-weight: 400;" aria-level="1">Increases readability of the IaC.</li>
</ol>
Translate the above described project layout into folder structure:

image3-3

folder structure

The separation of the development and deployment process is implemented with two git repositories &#8211; env/ and modules/. Notice the .git in the folder. Here, Terragrunt.hcl is simply a configuration file for modules specifically in the language of Terragrunt. The separation of cloud architecture components is implemented with subfolders app/ , mysql/, vpc/. The separation of deployment environments is implemented with subfolders prod/ , qa/ , stage/.
Check out our <a href="https://spacelift.io/blog/terragrunt-vs-terraform" target="_blank" rel="noopener">Terragrunt vs. Terraform comparison</a>.

One of the principles of software engineering is DRY (don’t repeat yourself). The same applies to IaC. There are at least two kinds of tricks you can use to DRY IaC:
<ul>
<li style="font-weight: 400;" aria-level="1">Modularization</li>
<li style="font-weight: 400;" aria-level="1">Configuration inheritance</li>
</ul>
<h2>1) Modularization</h2>
A <a href="https://spacelift.io/blog/what-are-terraform-modules-and-how-do-they-work" target="_blank" rel="noopener">Terraform module</a> is a way of creating a template of a cloud pattern, parameterizing, and reusing it. Like any other artifacts, modules can be stored and versioned in the registry. The official Terraform module registry is <a href="https://registry.terraform.io/" target="_blank" rel="nofollow noopener">https://registry.Terraform.io/</a>. You can also build your own private registry.
<h2></h2>

image2-3

AWS security group

<h2>2) Configuration Inheritance</h2>
<a href="https://terragrunt.gruntwork.io/docs/reference/config-blocks-and-attributes/#include" target="_blank" rel="nofollow noopener">Configuration inheritance</a> is a feature supported by Terragrunt. The concept is similar to class inheritance in object oriented programming, except that configuration inheritance serves the purpose of configuration reusability.
In the following example (also see the project layout above), we have a configuration file at the global level (global_vars.yaml) and configuration files at the environment level (environment_specific_vars.yaml). 
In global_vars.yaml, variables like account_id, region_name and repository_url can be defined, and in environment_specific_vars, these global variables will be inherited and present, additionally defining new environment level variables like vpc_id (usually we use separate vpc for different environments), environment_name, etc.

image4-3

Configuration Inheritance

In summary, configuration inheritance increases the reusability of configuration files and reduces the difficulty in maintenance.
Also, by running your <a href="https://spacelift.io/blog/terragrunt-with-spacelift" target="_blank" rel="noopener">Terragrunt commands on Spacelift</a>, you can extend the powers of Terragrunt with other features such as Spacelift <a href="https://docs.spacelift.io/concepts/configuration/context" target="_blank" rel="noopener">Contexts</a> and <a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">Policies</a>.
With Spacelift Contexts, you can define a collection of variables and files and then attach these to Spacelift stack(s). Spacelift Policies allow you to build rules using the <a href="https://spacelift.io/blog/what-is-open-policy-agent-and-how-it-works" target="_blank" rel="noopener">Open Policy Agent (OPA)</a> to govern your infrastructure as code and its automation. For example, you may want to disallow a specific resource type or even a certain way of configuring that resource type – you can easily achieve such a thing using a <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy" target="_blank" rel="noopener">Plan Policy</a>. You can also use <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a> to mix and match Terraform, Pulumi, and CloudFormation Stacks and have them talk to one another.

Last but not least, let’s review the concept of mono-repo and multi-repo. It has been pointed out by Hashicorp as a <a href="https://www.hashicorp.com/blog/terraform-mono-repo-vs-multi-repo-the-great-debate" target="_blank" rel="nofollow noopener">major architectural decision for IaC projects</a>, a view I share.
The problem is, there are two ways to organize code. In simple terms, mono-repo stores all code into one git repository (for example with multiple subfolders), whereas multi-repo separates them into multiple repositories.
Analogously, the relationship between mono-repo and multi-repo can be compared to monolith software architecture and microservice architecture. Mono-repo is intended to perceive the architecture as a whole and as evolving together. It is usually more suitable for small projects or big projects in prototyping. Multi-repo, on the other hand, facilitates collaboration but with extra overhead. Naturally, the more repos you have, the higher the maintenance cost, but also the more autonomous and self-service each repository is.

In this article, we reviewed several patterns of IaC architecture in a technology-agnostic way. All of these patterns can be easily implemented in Spacelift, as the product works natively with both <a href="https://docs.spacelift.io/vendors/terraform/" target="_blank" rel="noopener">Terraform</a> and <a href="https://spacelift.io/blog/introducing-terragrunt-native-support" target="_blank" rel="noopener">Terragrunt</a>.
Your workflows can be extended with other features like policies, and third-party integrations and you even have the possibility to bring your own runner image. 
Spacelift’s flexibility extends to other popular IaC technologies like Pulumi, CloudFormation, Ansible, and Kubernetes, where the same patterns keep appearing in slight variations.
We rooted the principles of IaC architecture design in software engineering concepts like inheritance, DRY, project layout, parameterization, and so on. After all, Infrastructure, as Code is coding infrastructure, and recognizing common patterns, is the recommended way to learn and apply IaC.

Spacelift is a sophisticated SaaS product for Infrastructure as Code that helps DevOps develop and deploy new infrastructures or changes quickly and with confidence.

Whenever you're embarking on a new journey or seeking to refine your foundational knowledge.

frame-8479

Frame 8479

5 Ways to Manage Terraform at Scale - Best Practices

What is tfsec? How to Install, Config, Ignore Checks

See common patterns of Infrastructure as Code architecture in Terraform and Terragrunt. Learn the differences between common patterns of IaC.

42-terraform-and-terragrunt

Patterns of infrastructure as code

Patterns of Infrastructure as Code : Terraform & Terragrunt

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

Mariusz Michalowski

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 benefits of multi-cloud infrastructure?

<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">11 Ways to Improve Your Infrastructure Orchestration</a></li>
</ul>

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.
<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 <a href="https://spacelift.io/blog/how-to-use-iac-to-optimize-your-multicloud-strategy" target="_blank" rel="noopener">IaC tool that supports multi-cloud</a>. 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. Read more: <a href="https://spacelift.io/blog/kubernetes-multi-cloud" target="_blank" rel="noopener">How to develop Kubernetes multi-cloud multi-cluster strategy</a>.
<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.

Business Benefits of Infrastructure as Code

Cloud Deployment Models - Types, Comparison & Examples

Learn what multi-cloud infrastructure is. Discover best practices, benefits, and tools to use in infrastructure with multiple clouds.

27-multi-cloud-strategies

What is Multi-Cloud Infrastructure? Benefits & Best Practices

Peter Christensen

Warsaw and Redwood City, June 15, 2021: Poland and US-based startup <a href="https://spacelift.io" target="_blank" rel="noopener">Spacelift</a> has raised $15m in Series B funding led by Insight Partners to scale its management platform for Infrastructure as Code in the US market. Existing investors Blossom Capital, Inovo Venture Partners, and Hoxton Ventures also participated in the round. 
This new investment will allow Spacelift to quadruple its engineering team to accelerate product development and to build out its commercial team in the United States. The company is headquartered in Redwood City, California, USA, and has an office in Warsaw, Poland. 
Over the past few years, managing cloud infrastructure has become significantly more complex. The migration of infrastructures to the cloud has created an explosion in DevOps, but few overarching tools exist to help teams of developers safely manage infrastructure as code at scale. Spacelift has created a plug-and-play platform that allows IaC DevOps teams to: define standardized infrastructures; understand their resources; build policies directly into their workflows and code; synchronize code across multiple projects and/or repositories; automatically detect and remediate resource drift, track lifecycle and cost of every managed resource; and take advantage of advanced workflow delegations and autonomous project teams. 
“With the growth of cloud-native development and DevOps practices, infrastructure as code has become the standard way to provision infrastructure, and Spacelift is addressing an acute need around infrastructure as code management, automation, and security and compliance,” said Josh Zelman, Vice President at Insight Partners. “Spacelift enables developers and DevOps teams to more easily and effectively manage infrastructure across all platforms. In speaking with DevOps teams within the Insight portfolio, we continuously heard about this need and the strength of the Spacelift platform. Insight is thrilled to partner with Spacelift and support its ScaleUp efforts in its next phase of growth.”
Spacelift is the only IaC management solution that extends IaC DevOps to encompass the complete set of IaC frameworks including Terraform, Pulumi and CloudFormation, with Ansible coming soon. Offering a consolidated approach to IaC is beneficial to engineering teams in large corporations that have been acquiring smaller companies that bring different infrastructures and to smaller but diverse organizations aiming to empower application developers. 
Marcin Wyszynski, co-founder and CEO at Spacelift, said: “Since we&#8217;ve founded Spacelift, we&#8217;ve seen a Cambrian explosion of new tools designed for teams to make the most of their cloud &#8211; ranging from cost management to audit to proactive security. Hence our vision of providing the most flexible and extensible platform for infrastructure and policy as-code is now more relevant than ever before. By using Spacelift, our customers get the whole cloud management story in one convenient package.”
Pawel Hytry, co-founder and COO at Spacelift, said: “Over the past few years, IT organizations relied on generic CI/CD tools, open-source components and custom-made solutions to manage their infrastructure. With increasing infrastructure complexity and development of infrastructure as code, this approach proves unscalable and error-prone. Spacelift addresses the issues of scaling and infrastructure complexity by providing a robust, <a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">specialized management platform for infrastructure as code</a>. We are eager to partner with Insight Partners and benefit from their experience in the developer tools space.” 
About Spacelift: 
Spacelift is building a platform to help DevOps teams manage their infrastructure-as-code performance for maximum optimization of scaling businesses. Founded in 2020, the management platform allows teams to manage complex cloud infrastructures simultaneously, providing visibility and collaboration. Spacelift has raised a total of $22.6M in funding from Insight Partners, Blossom Capital, Hoxton Ventures, Inovo Venture Partners, and the founders of Supercell and Yelp.
About Insight Partners:
Insight Partners is a leading global venture capital and private equity firm investing in high-growth technology and software ScaleUp companies that are driving transformative change in their industries. Founded in 1995, Insight Partners has invested in more than 400 companies worldwide and has raised through a series of funds more than $30 billion in capital commitments.

<ul>
<li><a href="https://spacelift.io/blog/why-devops-engineers-recommend-spacelift" target="_blank" rel="noopener">Why DevOps Engineers Recommend Spacelift</a></li>
<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;Infrastructure Problems that Spacelift Solves&quot;}" data-sheets-userformat="{&quot;2&quot;:4224,&quot;10&quot;:2,&quot;15&quot;:&quot;Arial&quot;}">Infrastructure Problems that Spacelift Solves</a></li>
<li><a href="https://spacelift.io/blog/alternative-to-atlantis" target="_blank" rel="noopener">Alternative to Atlantis – Spacelift</a></li>
</ul>

Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities for infrastructure management.

Infrastructure Drift Detection and How to Fix It With IaC Tools

$15M in a new funding round led by Insight Partners will enable  Spacelift to quadruple engineering headcount in Europe and build a sales and marketing organization in the United States.

series_b_blog-og

Spacelift raises $15m in Series B funding from Insight Partners

Peter is Head of Product Marketing at Spacelift. He brings over 20 experience in product marketing, having launched a
number of products ranging from complex network protocols to developer tools.

Why should business care about infrastructure as code

Kyle Galbraith

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.

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. 

Infrastructure as Code : Best Practices, Benefits & Examples

Get the newsletter

Recent posts

Common Patterns of Infrastructure as Code Architecture: Terraform & Terragrunt

What is Multi-Cloud Infrastructure? Benefits, Best Practices

Spacelift raises $15m in Series B funding from Insight Partners

Business Benefits of Infrastructure as Code

Share your data and download the guide