Infrastructure as Code

Once renting servers became easy, the number of machines climbed fast. Pick a size on a screen, press create, and two minutes later it's usable — so people made one whenever they needed one. The trouble was that none of those choices were written down anywhere. Which settings someone toggled lived only in that person's memory.

About six months in, the same thing happens everywhere. Something that ran fine on the development server dies in production. The two machines were supposed to be identical, and it turns out one of them had an extra setting switched on. Finding the cause takes a day, and even then nobody can say who turned it on, when, or why. A run space kept separate for a particular purpose is called an environment, and when environments drift apart like this, every check performed before release stops meaning much.

It gets worse when the person who built it leaves. Whoever remains has to work backwards from a running server to guess why it looks the way it does, and ends up too nervous to touch anything. Infrastructure as Code (IaC) pulls that memory out into files. Write the setup down as statements and the file outlives whoever wrote it.

Describe the setup you want in a file and hand the file to a tool that creates the real resources. In practice it runs in five steps.

1. Write the desired state into a file. Three servers of this size, one device in front of them splitting up incoming requests, access allowed only from this address range — all of it in a fixed syntax. The important difference is that you describe the result, not the sequence. How to get there — what order to create things in, what to build before what — is the tool's problem.
2. Put the file under version control, the system that keeps a history of code changes and merges them together. The moment the file lives there, who changed what and when is recorded for free. The question nobody could answer in the previous section is answered here.
3. Send the change through code review, where a colleague looks at it before it merges. Deleting the wrong firewall line takes the service down, so many teams review infrastructure changes harder than they review feature code, and require a second approval on anything touching access rules.
4. Run a preview before applying. The tool compares the current state against the file and prints the work it plans to do: add two servers, modify one security rule, destroy one database. A destroy showing up on that list usually means the file is wrong.
5. Apply it. From then on, no change happens in the console. Fix something by hand because you're in a hurry and the file no longer matches reality, and the next apply quietly reverts what you did.

The value is largest when the same setup has to exist several times over. Stamp development, staging, and production out of one file and there is no room for them to diverge. For a product that runs a separate environment per customer, a hundred of them come from the same file. And because the file can rebuild everything from nothing, the recovery plan stops being a document and becomes something you can execute.

It also fits teams whose setup changes often. When changes move through files, going back to yesterday's state is a single revert, so a rollback of a bad setting takes minutes. Setups held in memory turn the same task into hours of reconstruction.

A service that will run on one or two servers for years is a different story. Learning the syntax and porting the first setup eats two to three weeks, and what you get back is a few saved clicks. If the setup changes twice a year, those weeks never pay for themselves.

There are three real limits. First, the tool keeps its own record of what currently exists, and when that record breaks the tool sees a healthy server as missing and builds a second one. Second, hand-made changes keep drifting away from the file — someone patches a setting during a 3 a.m. incident, and the next apply silently undoes it. Third, one wrong line applied breaks things faster and more thoroughly than any person could. Clicking deletes one thing at a time; code deletes thirty. That's why never skipping the preview in step 4 is the habit that matters most.

"Don't change that in the console, put it in the code. It'll get wiped on the next apply."

A warning that a hand-edited setting no longer matches the file and will revert.

"The preview is showing two destroys. Look at it with me before I apply."

Resources nobody meant to remove are on the plan, which usually means the file is wrong.

"Staging is defined in code, but production is still something we built by hand."

The environment that matters most has no record behind it and should be moved first.

At Pagedeck, Theo owns the infrastructure files. Changing a server size or adding an allowed address range means editing the file, opening a pull request, and applying only after another engineer has looked at the preview alongside them. It's the same process the feature code goes through.

One busy afternoon Theo added servers through the console to get through a traffic spike. That day was fine, but two days later an unrelated apply reset the count and the service slowed down again. After that, even urgent changes go into the file first, and the console stays a place for reading rather than editing.

Many people read it as a tool that builds infrastructure automatically. One command and servers appear, so the impression is fair. What the practice actually does, though, is turn the setup into a record. Speed is a side effect; the payoff arrives six months later, when "why is this configured this way?" can be answered by opening a file. Teams that adopt it for speed keep patching things in the console when they're in a rush, and within half a year the file and reality disagree enough that nobody trusts the file.

Treating it as write-once is the other common mistake. Infrastructure files rot at the same rate as product code. Tool syntax changes, providers change theirs, a machine type gets retired, a rule stops being accepted. A file untouched for a year often won't apply cleanly, so it has to be run and repaired on a schedule to be there on the day you actually need it.