7.1 Why infrastructure as code

What this is and why it exists

Everything you have built so far, you built by describing it — and if you built it in a console, the description exists only in your memory. This module is where cloud work becomes engineering: the infrastructure moves into files, the files go into Git, and a change to production becomes something that can be read, reviewed, repeated and reversed. This first lesson is the argument, because the tools make no sense until the argument does.

The vocabulary

• Infrastructure as code — defining infrastructure in files that a tool applies, rather than by hand.
• Drift — the gap that opens between what the files say and what actually exists.
• Snowflake server — a machine configured by hand over time, unique, undocumented, and unreproducible.
• Declarative — you write the end state and the tool works out the steps.
• Imperative — you write the steps and they happen in that order.
• Idempotent — applying the same description twice produces the same result as applying it once.
• Environment — one instance of the whole system: development, staging, production.
• Plan — a preview of what a tool would change, produced before anything changes.

The mental model

Start with the failure the console produces, because it is not the one people expect. The console is fine for one person, once. What it cannot do is answer questions later: what exactly is running, who changed this, why, and what did it look like last Tuesday. Six months in, nobody can rebuild the environment because nobody knows what it contains — and the machine that everyone is afraid to restart is not a technical problem, it is a documentation problem with a power cable.

Drift is the same failure in motion. Somebody fixes an incident at two in the morning by changing a setting directly, and now the files say one thing and reality says another. The next apply either reverts the emergency fix or fails confusingly. Infrastructure as code does not prevent drift; what it gives you is the ability to see it, because a plan against reality shows the difference. The rule that makes this work is social rather than technical: emergency changes are allowed, and the same day they must go back into the files.

Declarative and imperative is the next distinction, and declarative wins for infrastructure for one reason — the tool must handle the case where things already partly exist. An imperative script that creates a network fails on the second run because the network is there; a declarative description says "this network should exist", and applying it twice is the same as applying it once. That property, idempotence, is what lets you run the same description against an empty account and against a live one and get the same answer.

Environments then become almost free, and this is the point where the effort pays back. Staging and production are the same code with different values — a smaller instance size, a different address range, a different domain. Not a copy of the code with edits, which drifts apart within weeks, but the same files with a different variable file. When that is true, "make me a fresh environment" is a command rather than a project, and testing a change in staging actually tells you something about production, because the two are the same description.

And the last piece is the one that changes how a team works: an infrastructure change becomes a change you can review. Somebody proposes it, somebody reads the diff, the plan output shows exactly what will be created, changed or destroyed, and the discussion happens before production rather than during the incident. The specific thing to look for in a review is the word destroy — most infrastructure mistakes that cost real money are visible in a plan as a resource being replaced rather than updated, and the plan says so plainly if anyone is reading.

What you should now be able to explain or do

Explain what a console cannot tell you six months later, and why the machine nobody dares restart exists. Define drift and say what infrastructure as code actually does about it — including the rule that has to be social. Give the difference between declarative and imperative, and say why idempotence matters for infrastructure specifically. Describe how one codebase produces several environments. Say what to look for when reviewing a plan.

Check yourself