Cloud
Infrastructure as code is for small teams too
The case for scripting your cloud environment even when there are only two of you.
There is a belief that infrastructure as code is an enterprise practice, something for large platform teams. We think the opposite. The smaller the team, the more it benefits from having its environment written down as code.
What it gives a small team
Memory. When the person who built the environment leaves, the code stays. It shows exactly what exists and why.
Recovery. If an environment is destroyed, by mistake or by an attacker, the code rebuilds it. Recovery becomes a procedure instead of a reconstruction.
Review. Changes go through a pull request. A second person looks at them. Mistakes get caught before they reach production, and the history explains every change.
Consistency. Development, test, and production environments are built from the same definitions. The classic "it worked in test" problem shrinks.
How to start
Do not try to convert everything at once. Pick the next new thing you build and write it as code with Terraform, Bicep, CloudFormation, or Pulumi. Store it in version control. Add a simple pipeline that plans and applies it. Then gradually bring existing resources under management, starting with the ones you change most often.
Common objections
"It slows us down." At first, yes. After a few weeks, it speeds everything up, because you stop repeating yourself and stop debugging drift.
"We do not have time to learn it." The core of any of these tools can be learned in a few days. The concepts transfer between them.
"Our environment is too small." Then it will take an afternoon to codify, and you will never again wonder how it was set up.
We build every environment this way, including our own, and we hand over the code with documentation so the agency can keep going without us.