Infrastructure as Code: How Far Should It Go?

Infrastructure as Code has an important place in core shared infrastructure. Networks, shared services and the foundations that many workloads depend on benefit from consistent definitions, controlled changes and a dependable way to rebuild.

The harder question is how far that approach should extend.

Once an organisation has established IaC for its shared infrastructure, it can seem natural to make it the standard for every workload, department and team. Everything should live in a repository. Every change should go through a pipeline. Everything should be managed as code.

That is a much bigger decision than choosing how to provision infrastructure. It changes how people request, approve, deliver and support services. The benefits may be real, but so is the distance between the organisation that exists today and the one this approach assumes.

A shared foundation does not settle every workload decision

Core infrastructure serves many teams. Consistency matters because a change can affect services well beyond the team making it. Investing in maintained definitions, experienced reviewers and a controlled deployment process makes sense here. A well-designed platform engineering approach can give teams a dependable foundation and remove considerable duplicated effort.

Individual workloads, however, have different circumstances.

One team may build and deploy software every day. Another may operate a vendor application that changes only a few times a year. A department may depend on experienced administrators who understand its systems deeply but have little reason to use version control in their current work.

Those teams do not start in the same place. Giving them the same tooling does not give them the same ability to use it.

A standard can describe the destination. It cannot, by itself, provide the skills, capacity and support needed to get there.

“Everything as Code” carries an operating model with it

The promise is attractive: repeatable deployments, visible changes, consistent controls and less manual effort. A utopian environment where everything is tracked, secure, governed, meshed, efficient and documented, all with seamless AI integration. A place where the problems of the past and the services of the future are auto-magically sorted.

But consider what that promise asks of someone whose work has previously centred on administering a service through familiar tools and an established change process. Perhaps a team who have never created a branch or rebased anything. Maybe they think Terraform is something used for building cities on Mars.

Now they must understand repositories, branches, pull requests, plans, pipelines, modules and state. They need to know which part of the process has failed, whether a proposed change is safe and how to recover when the result is unexpected.

Then comes the wider transformation vocabulary: data mesh, policy as code, dependency graphs, drift, reconciliation and RAG architecture. Some of these belong to different disciplines, but they can all land on the same team’s desk as part of the same grand vision.

These concepts may be familiar to the people designing the platform. They can be alien to the people expected to adopt it.

That is a learning and service-design problem the organisation must fund. It should not be dismissed as resistance to change.

If the new process makes a routine task harder for its intended users, “they need to learn Git” is only part of the answer. The organisation also needs to ask whether it has chosen the right interface for those users.

The transition is part of the investment

A demonstration usually starts with a clean environment and someone who already understands the tools.

An established business starts with live services, existing responsibilities, uneven documentation and people who are already busy keeping things running.

Moving to IaC means finding time to understand what exists, decide how to represent it, migrate it safely and teach people how to operate it. During that transition, the existing service still needs support.

There is also an ongoing commitment. Someone must maintain the definitions, deployment process, permissions and supporting tools. Someone must help when a team encounters a problem it cannot resolve.

I have seen IaC and platform engineering done well. I have also seen technically impressive platforms struggle badly when the next step was simply to ask the business to “move their stuff in”. Building the platform had received the attention; helping teams adopt it had not received enough.

The investment therefore has three parts:

The cost and limitations of the current approach.
The work required to make the transition.
The capability needed to sustain the new approach.

All three need to be weighed against the expected benefits and the risks involved. Keeping the current approach has a cost, but changing it introduces costs and risks of its own.

A business case that counts the manual effort removed while leaving out the transition and ongoing ownership is incomplete.

Preserve the people who understand the service

"Whoever owns the knowledge of the system, maintains the system"

An experienced administrator may know which dependency is fragile, which maintenance operation takes longer than expected and which apparent fault is actually normal behaviour.

That knowledge matters whether the infrastructure is managed through code or a console.

A migration can improve how this knowledge is recorded and shared. It can also create a gap between the people who understand the service and the people who can operate its new deployment process.

If every routine change now needs one of a handful of automation specialists, the organisation has created a new dependency. The service may have a repository and a pipeline while becoming harder for its existing team to support.

A successful transition brings operational knowledge into the new approach and gives the people responsible for the service a workable way to use it.

Teams do not all need to interact with code directly

There is a useful distinction between infrastructure being managed through code and every user having to work with that code.

A platform team might maintain the shared definitions and deployment process while other teams use a service catalogue, a form or another supported interface. Some teams may benefit from working directly with repositories. Others may need a simpler route for a small set of well-understood changes.

There will also be workloads where retaining an established management process is a reasonable choice, particularly where change is infrequent and the benefit of migration is limited.

These boundaries need clear ownership. People should know which resources are managed through which process, who can change them and how exceptions are handled.

The aim is a model people can operate confidently, with controls proportionate to the service.

Choose the extent deliberately

I would start with a strong case for IaC in core shared infrastructure, then assess its extension according to the workload and the team responsible for it.

Where does repeatability remove a real operational problem? Which teams are ready to adopt the workflow? Which need training, migration support or a different interface? Where would the transition consume more capacity than the improvement justifies?

The answers can change over time. A team may begin with a supported request process and later take direct ownership of its definitions. A workload may become worth migrating as its scale or rate of change increases.

An organisation can make substantial progress without requiring every team to reach the same destination at once. Some workloads may continue to be better served by a different approach.

Infrastructure as Code is an important capability. Extending it across a business is an organisational change, and it needs to be planned, supported and funded as one.