Why infrastructure as code

The problem with click-ops

Infrastructure is everything your application runs on: virtual machines, networks, firewalls, load balancers, databases, storage buckets and DNS records. In a small project, someone usually creates these by clicking in the cloud console (the website of AWS, Azure or Google Cloud). People call this "click-ops".

Click-ops works for one server on day one. It fails as the system grows. Nobody remembers which 40 settings were chosen. The staging server is slightly different from production, so a bug appears only in production. A new engineer cannot see why a firewall port is open. And if the region has an outage, nobody can rebuild the whole setup quickly, because the "documentation" is in one person's memory.

A server that was built and then changed by hand many times becomes a snowflake server: unique, fragile and impossible to copy exactly. Everyone is afraid to touch it.

What infrastructure as code gives you

Infrastructure as code (IaC) means describing infrastructure in text files and letting a tool create it. Because the files are plain text in Git, you get all the habits you already use for application code.

• Repeatability: the same files build dev, staging and production, so they really are the same.
• Review: a change is a pull request. A teammate can see "this opens port 22 to the whole internet" before it happens.
• History and audit: git log shows who changed what and why. Banks and hospitals need this for audits.
• Disaster recovery: if a region or an account is lost, you run the code again in another place.
• Speed: a new environment for a test or a new customer takes minutes, not days of tickets.

Declarative versus imperative

An imperative approach lists the steps: "create a VM, then attach a disk, then open port 443". A declarative approach describes the end result: "there should be one VM with this disk and port 443 open". The tool compares that wish with what exists and works out the steps itself.

Declarative code is easier to rerun. If the VM already exists, a declarative tool does nothing. An imperative script would try to create a second VM, or fail. Terraform, CloudFormation and Kubernetes manifests are declarative. A bash script that calls the cloud CLI is imperative.

Idempotency

An operation is idempotent when running it once or ten times gives the same result. "Make sure the bucket exists" is idempotent. "Create a bucket" is not. Good IaC is idempotent: the second run reports "no changes". That makes it safe to run often, for example on every merge.

desired (code):  web-vm, logs-bucket, db
actual (cloud):  web-vm, old-test-vm

plan:  create logs-bucket, create db, delete old-test-vm
       web-vm is unchanged, so nothing happens to it

Three families of tools

Pulumi lets you write infrastructure in general programming languages such as Python or TypeScript. CloudFormation is AWS-only and uses YAML or JSON. Terraform works with hundreds of providers (AWS, Azure, Google Cloud, Cloudflare, GitHub and more) using one language, HCL. This module uses Terraform; the next module covers Ansible.

Immutable infrastructure

Mutable infrastructure means you log in and change running servers (patch them, edit files). Immutable infrastructure means you never change a running server: you build a new image with the change, start new servers from it and delete the old ones. Containers work this way too. Immutable servers cannot drift into snowflakes, and rollback is simply "start the old image again".

Common mistakes