Why Infrastructure as Code

In Chapter 1 you met the progression console → CLI → API → Infrastructure as Code, and saw why clicking through the console ("ClickOps") doesn't survive contact with real production. This chapter is the destination of that progression. Infrastructure as Code (IaC) means defining your cloud infrastructure in text files — code — and using a tool to create and manage it, instead of clicking or typing one-off commands. It is one of the most important shifts in modern cloud engineering, and once you have it, you never want to go back.

The problem: infrastructure you can't reproduce

Recall the failures of clicking infrastructure into existence:

• It's not repeatable. You set up a server, a database, a network, a dozen security rules by hand. Now build the identical thing for a staging environment, or recover it after an accident. The only record is your memory, and memory is lossy. The staging environment ends up subtly different from production — and subtle differences cause the worst bugs.
• It's not reviewable. A teammate clicks a checkbox that opens a database to the internet. There's no pull request, no diff, no second pair of eyes. The mistake ships silently.
• It drifts. Over months, people make little manual tweaks. Nobody knows the true, current state of the system anymore. This slow divergence between what-you-think-you-have and what-you-actually-have is called drift, and it's a defining pain of un-coded infrastructure (we devote a whole lesson to it).
• It doesn't scale to humans. Onboarding a new engineer means narrating tribal knowledge. Nothing is self-documenting.

The solution: describe the infrastructure as text

IaC fixes every one of those by making your infrastructure a text file you commit to version control, exactly like application code. The file is the source of truth. To create the infrastructure, you run a tool that reads the file and makes the necessary API calls. To change it, you edit the file and re-run the tool.

Suddenly your infrastructure gains every benefit that code already has:

• Repeatable — the same file produces the same infrastructure, every time, in any environment. Build prod and an identical staging from one definition.
• Reviewable — changes are pull requests with diffs. "This PR opens the database to the internet" is visible and can be blocked before it ships.
• Versioned — your whole infrastructure history lives in git. See who changed what, when, and roll back a bad change.
• Self-documenting — the file is the documentation of what exists. New engineers read the code.
• Automatable — a pipeline can apply infrastructure changes automatically (this is where IaC meets CI/CD in Chapter 5).

:::tip This is the durable idea The specific tools change, but the principle — infrastructure defined as version-controlled, reviewable, repeatable code — is one of the most durable ideas in cloud. It underpins everything modern: reproducible environments, GitOps, platform engineering. Internalize why before you learn which tool. :::

Declarative vs imperative: describe the destination, not the route

There are two ways code can manage infrastructure, and the distinction matters:

• Imperative — you write the step-by-step instructions: "create a VM, then create a disk, then attach the disk, then..." Like CLI commands in a script. The problem: if you run it twice, it may try to create everything again and fail, and it doesn't know how to change existing infrastructure to a new desired shape.
• Declarative — you describe the desired end state: "I want one VM with this disk attached, on this network." The tool figures out the steps to get there from wherever you currently are. Run it again and it sees everything already matches and does nothing. Change the file and it computes the difference and applies just that.

Modern IaC is overwhelmingly declarative, and for a deep reason: declarative tools are idempotent — running them repeatedly converges on the same end state without duplicating work. You declare what you want; the tool reconciles what is to match. This is the model behind Terraform, and the same reconciliation idea reappears in Kubernetes (Chapter 4) and GitOps (Chapter 5).

That loop — declare desired state, let the tool compute and apply the difference — is the heartbeat of IaC, and you'll see it again and again.

The landscape, briefly

You'll meet the tools properly in the next lessons, but to orient you:

• Terraform (and its open-source fork OpenTofu) — the dominant declarative IaC tool, using a purpose-built configuration language. The default thing to learn.
• Pulumi — declarative IaC written in general-purpose programming languages (Python, TypeScript, Go) instead of a special config language.
• Cloud-native tools — each provider has its own (AWS CloudFormation, etc.), useful when you're committed to one cloud.

We focus on Terraform/OpenTofu because it's the most widely used, is cloud-agnostic (the same tool provisions AWS, GCP, and Azure), and teaches the concepts cleanly.

:::note Terraform vs OpenTofu — why two names Terraform's license changed in 2023, prompting the community to create OpenTofu, an open-source fork that is a near drop-in replacement. For learning, they're effectively identical — the concepts, the language (HCL), and the workflow are the same. We'll say "Terraform" generically; everything applies to OpenTofu too. (Which to choose in production is a dated licensing/governance question.) :::

Why it matters

Infrastructure as Code replaces clicking and one-off commands with infrastructure defined as version-controlled text, making it repeatable, reviewable, versioned, self-documenting, and automatable — and killing drift, the silent divergence that plagues hand-managed systems. Modern IaC is declarative and idempotent: you describe the desired end state and the tool computes and applies the difference, converging safely no matter how many times you run it. That declare-and-reconcile loop is one of the most durable ideas in cloud and recurs in Kubernetes and GitOps. Next, we make it concrete by writing real Terraform.

Next: Terraform basics →