Hey there! Today we're talking about Infrastructure as Code (IaC) - that thing your DevOps friend (if you have one) won't shut up about at lunch. If you've been nodding along while secretly having no idea what they're talking about, this post is for you.

What is Infrastructure as Code anyway?

Remember the old days? You'd SSH into a server, run a bunch of commands, install packages, edit config files, and pray to the server gods that you didn't forget anything important. Then you'd do it all again on the next server. And the next. And when something broke, you'd scratch your head trying to figure out what was different between your production and staging environments.

Infrastructure as Code is exactly what it sounds like - you write code that describes your infrastructure, and then magical tools make it happen. Instead of clicking through AWS console or manually configuring servers, you describe what you want in code, and poof! Infrastructure appears.

With just a few lines of code, you can create servers, networks, databases, load balancers - pretty much anything you'd normally click around for in a cloud console. No more forgetting to tag resources or wondering "how did I set this up again?"

Why should I care? (AKA benefits that will make your life better)

No more "works on my machine" syndrome

Picture this: New developer joins the team. You tell them to set up the dev environment. Three days later, they're still fighting with configurations, and you're both questioning your career choices.

With IaC, it's more like:

1. Clone repo

2. Apply the infrastructure code in a new workspace

3. Go get coffee

4. Come back to a working environment

That's it. Everyone gets the same setup. Every. Single. Time.

Version control all the things!

"Who changed the security group and why?" - every DevOps engineer on friday afternoon during an outage.

When your infrastructure is code, it lives in your repo. It gets reviewed in PRs. It has commit history. It has blame (the git kind, not the pointing fingers kind... well, maybe both).

$ git blame terraform/security_groups.tf
86ab4f72 (Henk de Vries 2023-04-15) resource "aws_security_group" "api" {
cb80f123 (Bob Janssen   2023-05-20)   ingress {
cb80f123 (Bob Janssen   2023-05-20)     from_port   = 443
cb80f123 (Bob Janssen   2023-05-20)     to_port     = 443

Oh look, Bob opened HTTPS access last month! Mystery solved.

Scaling without the tear

With IaC, scaling is just changing a number and letting the code do its thing:

# From this
instance_count = 5

# To this
instance_count = 100

Done. Go have lunch while your fleet expands.

Recommended tools

When it comes to IaC tools, there are several options out there, but I'll cut to the chase - our preferred tool is Terraform/OpenTofu. It’s 2 different tools that work the same, OpenTofu is the open-source fork of Terraform.

Terraform/OpenTofu: The powerhouse of infrastructure code. These tools use a declarative approach (you say what you want, not how to get there), work with practically any cloud provider, and have enormous community support. The HCL syntax is purpose-built for describing infrastructure, and the ecosystem of providers and modules means you're never starting from zero.

Why Terraform/OpenTofu? They're:

• Cloud-agnostic (works with many platforms, search for yours on https://registry.terraform.io/)

• Well-documented

• Have strong state management

• Provide dry-run planning

• Support modular design

• Have thriving communities

Whether you're managing resources on AWS, GCP, Azure, or a mix of all three plus your on-prem stuff, Terraform/OpenTofu has you covered. If you're just starting with IaC, this is where I'd recommend jumping in.

Common pitfalls (don't say I didn't warn you)

Treating it like regular code

Infrastructure code needs special care. You're not just affecting data - you're creating and destroying actual resources that cost money and host critical services.

Always use:

• Proper planning

• Dry runs/plan phases

• Incremental changes

• Testing in non-production environments first

The dreaded state file

Most IaC tools keep track of what they've created in a state file. Lose that, and things get... interesting. Always:

• Use remote state when possible

• Back up your state files

• Store them securely (they can contain secrets!)

In general our workflow is: set up a blob storage or S3 account by hand to use that as a remote state location in the cloud provider of choice. This way you can easily collaborate on deploying the infrastructure and let the deployment be handled by CI/CD pipelines (see below)

Let's get practical - a mini tutorial

Want to see how easy it is to get started? Here's a super simple example using Terraform to create an S3 bucket:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "5.31.0"
    }
  }
  # this piece states the remote state location
  backend "s3" {
    bucket = "<BucketName>"
    key    = "<StateFileName>"
    region = "eu-west-1"
  }
}

provider "aws" {
  region = "eu-west-1"
}

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-amazing-company-assets"

  tags = {
    Environment = "Production"
    Department = "Marketing"
  }
}

Run terraform apply and boom - bucket created, properly tagged, and documented in your code.

The CI/CD power combo

The real magic happens when you combine IaC with CI/CD pipelines. Imagine this workflow:

1. Push infrastructure code change to repo

2. CI system runs validation and plan and writes the plan to the pull request

3. Code review happens with the proposed changes

4. After approval, pipeline applies changes

5. Your infrastructure is adjusted, safely and automatically

6. You have a log of all the changes applied to your infrastructure

It's like having a robot assistant who never gets tired of provisioning resources.

Getting started without losing your mind

Want to dip your toes in the IaC waters? Here's how:

1. Start small - Don't try to codify your entire infrastructure at once

2. Pick one tool - Learn it well before branching out

3. Non-critical first - Begin with dev or test environments

4. Incremental adoption - Gradually bring more of your infrastructure under code control

Even converting just your development environments to IaC can save tons of time and headaches.

Wrapping up

Infrastructure as Code isn't just a trendy DevOps term - it's a survival strategy for modern engineering teams. If you're still clicking around in cloud consoles to set up resources, you're doing it the hard way.

Start small, pick a tool that matches your team's skills, and begin the journey. Your future self will thank you when onboarding new team members takes hours instead of days, and when your 2am troubleshooting sessions become a thing of the past.

Have you tried IaC yet? I'd love to hear about your experience! Just starting starting and need some more pointers? Don’t hesitate to shoot me a message at nathan@wolk.work.