Infrastructure as code for small teams

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. Most advice about infrastructure as code assumes a team that does not exist at your size. Here is the version that does not.

The bill is a design document: it tells you exactly what your architecture actually does. Write the reasoning down alongside the decision, because the reasoning is what changes first.

What to keep

Clicking around a console is not a reproducible environment. That sounds obvious written down. It is still the thing most often skipped. It is the sort of thing that looks like polish right up until it costs you an enquiry.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. In practice this is a scheduling problem more than a technical one.

What good looks like

Rebuilding from scratch should be a routine operation. It is worth being explicit about, because assumptions differ quietly. If two people in the business would answer this differently, that gap is the actual problem.

How to tell if yours is fine

Operability is a feature, and it has to be built rather than bought. Three things worth confirming about infrastructure as code before you move on:

• Someone can say what the current setup is without going to look
• Review infrastructure changes the same way you review code — and you know whether that is true here
• There is a way to tell whether the last change to this helped

The point is not perfection, it is knowing which of these you have consciously chosen to skip.