If you’re anything like me, you like to try out all the shiny new things that make their way into your news feed; one of the newer things in software development that’s been growing over the past few years is Infrastructure-as-Code (IaC). After having focused heavily on learning, applying, and teaching IaC for the past ~4 years, I’ve realized it’s important to understand when IaC is worth using.

What exactly is IaC?

Infrastructure-as-code (IaC) is a method of defining, managing, and deploying infrastructure and its dependencies using code, rather than manually configuring resources through a user interface. This approach offers several benefits for organizations and teams looking to streamline their infrastructure management processes and improve the efficiency, reliability, and scalability of their infrastructure. While all of this sounds great, it’s important to understand that these benefits come with all the usual costs of adopting a new technology.

The Cost of Adoption

Learning Curve

This is the most expensive piece of the puzzle. With IaC, not only do they need to learn how to use a new framework (something like Pulumi or AWS CDK) but also how the underlying infrastructure should work (something like AWS, Azure, or GCP). From what I’ve seen, it’s unlikely that developers have a complete understanding of the different structural elements that host an application, so the learning curve can be considerable.

Time for Refinement

Once your team understands how to work with IaC, they’ll start noticing all of the security gaps that their constructs may have inadvertently created and finding patches to secure them. This is arguably the most important allowance developers need to feel the deployments are stable and can take a good amount of time before getting there.

Frustration

A lot of developers feel frustration when learning infrastructure for a variety of reasons but I see the main one being something along the lines of: "Why are we adopting this if we can do the same thing with this other thing?" That statement is easily debunked however when you start throwing real-life situations that will force the infrastructure to evolve like multi-tenancy, multiple data sources, specific tools for indexing and/or machine learning, and most importantly, cost. Still, the frustration will always be floating around until the developer feels comfortable with the technology and that may take years. Nobody wants unhappy developers because there is a huge cost to filling their position if they decide to leave.

So when should I adopt IaC?

When you have a large and complex infrastructure

If your infrastructure is large and complex, with many interconnected resources and dependencies, using IaC can help you manage and maintain it more effectively. With IaC, you can use code to define your infrastructure in a consistent, predictable, and organized way, which can make it easier to understand and modify as your infrastructure evolves over time.

When you need to deploy infrastructure quickly and consistently

IaC can help you deploy infrastructure quickly and consistently, whether you're setting up a new environment or scaling an existing one. By using code to define your infrastructure, you can automate the process of provisioning and configuring resources, which can save time and reduce the risk of errors.

When you need to enforce infrastructure standards and best practices

IaC can help you enforce standards and best practices across your infrastructure through sharing constructs. This can help ensure that all projects and environments are consistent and adhere to your policies and guidelines.

When you need to track changes to your infrastructure

Using IaC can help you track changes to your infrastructure over time because you can use version control tools like Git to track changes. This can be especially useful for organizations with multiple teams working on different parts of the infrastructure as it can help ensure that changes are coordinated, reviewed, and easily previewed before they are implemented.

This article is also published in Differential's Blog, make sure to follow our team as well!