Platform & DevOps·topic 5 of 9
Infrastructure described in a file
Writing the infrastructure down is the easy half. The hard half is that the file, the state and the real cloud are three different things that disagree, and this is the vocabulary of that disagreement.
Read in order · tick what you already know
- 01
the tool's record of what it built is a third thing, sitting between your file and the real cloud, and all three can disagree.
Infrastructure state
- 02
the entire record of what your infrastructure is lives in one JSON file, and it contains the database password in clear.
State file
- 03
two people applied at once, and the second was refused rather than allowed to interleave writes into the same record.
State locking
- 04
the tool prints exactly what it will create, change and destroy, and you read the destroy list before typing yes.
Plan and apply
- 05
you never say what order to build things in; the tool works it out from which resource references which.
Resource graph
- 06
the tool speaks to each cloud through a plugin, and upgrading that plugin can rewrite parts of your plan on its own.
Infrastructure provider
- 07
the team's standard service takes six inputs and produces thirty resources, and nobody writes the thirty by hand any more.
Infrastructure module
- 08
the resource already exists because somebody built it in the console, so you tell the tool to adopt it rather than recreate it.
State import
- 09
somebody fixed it in the console during an incident, and the next apply politely undid the fix.
Infrastructure drift
- 10
a nightly job plans against production and tells you that fourteen things no longer match the code, before the next deploy does.
Drift detection
- 11
you changed one field the API cannot update in place, and the plan quietly says destroy then create.
Resource replacement
- 12
one careless change proposed to destroy the database because everything lives in a single state, and the plan was long enough not to be read.
Apply blast radius
- 13
you ran the whole thing again after a network error and it created nothing new, because everything it wanted already existed.
Idempotent provisioning
- 14
the first run fails on something, the second gets further, and the third finally settles — and everybody calls that normal.
Convergence
- 15
the machine, the network and the disk are created and exist, and nothing has yet been installed on any of them.
Provisioning
- 16
an agent installs the packages, writes the files and restarts the service on machines that already exist, over and over.
Configuration management
- 17
you ran the package upgrade on the running fleet, and now the machines differ from each other by whatever failed halfway.
In-place upgrade
- 18
there is one machine everyone is afraid to reboot, and its configuration exists only in the history of who logged in.
Snowflake server
- 19
nobody knows the names of the machines, and the fix for a sick one is to terminate it rather than to log in.
Cattle not pets
- 20
the machine boots already containing the agent, the runtime and the hardening, so start-up is thirty seconds rather than six minutes.
Golden image
- 21
a scheduled job boots a base machine, applies the configuration, snapshots it and publishes a new version every week.
Image baking
- 22
the state bucket and the pipeline's own permissions had to exist before the tool that creates everything could run once.
Infrastructure bootstrapping
- 23
a new team gets an account that already has the network, the logging, the guardrails and the billing tags applied.
Cloud landing zone