Infrastructure as Code: industrialising without kidding yourself

Managing infrastructure through versioned definition files, rather than through consoles and manual procedures, changes three things: the environment becomes reproducible, every change is tracked and reviewed, and configuration drift stops being inevitable.

None of that comes free. Infrastructure as code shifts the complexity: it asks development skills of teams that did not necessarily have them, and it fails when you start migrating before the foundations are in place.

What we are trying to fix

The manual approach always produces the same symptoms: unique servers nobody dares touch, documentation lagging behind reality, test environments that no longer resemble production, and rebuilding that turns out to be impossible after a major incident.

The declarative approach answers each of those points, provided everything goes through code — the slightest change made by hand in a console reintroduces drift.

The tools, and what they really do

Terraform provisions infrastructure: networks, machines, managed services, across one or several providers. Its main value is not the language, it is the execution plan: knowing exactly what is about to change before applying it.

Ansible configures what runs inside: packages, files, services. Agentless, in YAML, it remains the right tool for post-provisioning configuration and recurring operations.

Kubernetes orchestrates containerised applications with declarative manifests. It is a structural choice: it brings self-healing and scaling, at the cost of operational complexity you have to be ready to take on.

These three tools do not replace one another, they complement each other — provision, configure, orchestrate.

Putting it in place: the order matters

Phase 1 — Framing

Inventory of the existing estate, identification of dependencies and constraints, choice of tools, definition of the path, and training for the teams. That last item is not optional: a team that has tooling imposed on it will work around it.

Phase 2 — Laying the foundations

This is the phase most often rushed, and the most expensive to fix afterwards:

• Git repository: project structure, branching strategy, mandatory review.
• CI/CD pipeline: syntax validation, static analysis, automatic plan on every merge request.
• State management: remote backend, concurrent locking, backup. A lost or corrupted Terraform state is a major incident.
• Secret management: central vault, rotation, a strict ban on plaintext secrets in the repository.
• Monitoring: observability of the infrastructure itself, not only of the applications.

Phase 3 — Migrate gradually

In waves, from the least risky to the most critical: development and test environments, then non-critical production services, then critical applications with a rollback plan, and finally the complex legacy infrastructure — the one whose dependencies nobody fully knows any more.

Practices that hold up

Structure. Reusable modules rather than copy-paste between environments, a clean separation of environments, consistent naming conventions.

Security. Least privilege, encrypted secrets, a complete audit trail, automatic policy validation before applying.

Testing. Syntax validation, unit tests for modules, integration tests on a disposable environment, and always a reviewed plan before applying.

Monitoring. Infrastructure metrics, proactive alerting, and continuous compliance checking — to spot the gaps between the declared state and the real one.

The most common trap

Wanting to describe everything at once. Bringing existing infrastructure into code is done in coherent scopes, starting with whatever gets recreated most often. A repository holding 100% of the infrastructure that nobody dares apply for fear of breaking production has no value: the goal is not coverage, it is confidence.