Photo: Google Gemini · AI-generated
Most writing about infrastructure as code is aimed at companies running thousands of services. If you run four, it is easy to conclude the whole subject is not for you.
That conclusion is wrong, but for a reason the usual arguments miss. The case for IaC at a mid-sized company is not scale. It is memory.
The question it actually answers
Somewhere in your production environment is a setting that someone changed at 11pm two years ago to fix an urgent problem. It worked. It was never written down. That person may no longer work there.
Multiply that by a few years and you get an environment nobody can fully describe — which is fine until the day you have to reproduce it. A new test environment, a migration, a failed server, an auditor asking what is actually running.
IaC is how you make the answer to “what is in production” a file someone can read, rather than a reconstruction from memory and screenshots. That value does not depend on how many services you run. A single environment nobody can rebuild is already the problem.
It is not a hyperscale concern
The common assumption is that this is a cloud topic, and specifically a big-cloud topic. It is not.
The purchasing portal we built for an industrial machinery manufacturer runs on premises, with its infrastructure and deployment defined and automated rather than hand-configured. The subcontractor portal for a construction client runs on a private German cloud, chosen for data-residency reasons, with the same discipline applied.
Neither is a hyperscaler deployment. Both benefit from exactly the same thing: the environment is described somewhere other than in someone’s head. If anything the argument is stronger off-hyperscale, because you cannot fall back on a managed console that quietly remembers your configuration for you.
The cargo cult failure
The way this goes wrong for smaller teams is copying the tooling of companies that have a platform team, without having one.
Kubernetes because a conference talk said so. A service mesh for six services. A module structure designed for fifty engineers, maintained by three. The result is infrastructure that is now both complex and unfamiliar — you have added a second system to understand, and the original problem is still there.
The honest test is not whether your setup resembles a big tech company’s. It is whether a competent engineer who joined last month could stand up a working environment from the repository, without asking anyone. If yes, you have enough. If no, no amount of fashionable tooling fixes it.
Enough, roughly in order
For a mid-sized company, the useful progression is boring and short.
Start with environment definition — the servers, networks and services described in version control. Then deployment, so releases are a pipeline run rather than a person following a checklist. Then configuration, so the difference between environments is a file rather than folklore. Then monitoring, because an environment you can rebuild but not observe is only half solved.
You can stop when the thing is repeatable. There is no prize for continuing.
What it buys you on a bad day
The payoff is not visible on a good day, which is why it is hard to fund.
With CarLicence — a real-time licence renewal API that partners embed in their own websites, apps and ATMs — the team covers development, cloud infrastructure and DevOps together: CI/CD, environment management, production monitoring. New integration partners keep arriving. None of them are a special event, because standing up and changing environments is routine rather than an operation someone has to remember how to perform.
That is the whole return. Not elegance, not resembling a hyperscaler. Just fewer days where the answer to “can we rebuild this” is a long silence.
If your production environment only exists in one person’s memory, we should talk.