In October 2015, I was proud—and more than a little nervous—to join a configuration management panel at Leeds DevOps.
The event was hosted near Leeds station at the DoubleTree by Hilton. All 100 tickets had been taken, with a waiting list for anybody hoping to get into the room. The immediate subject was Puppet, but the conversation was really about a larger change happening across engineering.
Infrastructure was becoming software.
Why configuration management felt important
Without configuration management, a server could become a collection of decisions remembered by one person:
- packages installed interactively;
- configuration changed directly in production;
- fixes documented after the event—or not at all;
- environments that were nominally identical but behaved differently;
- recovery plans that depended on reconstructing history from shell commands.
Puppet offered a different model. Describe the desired state, keep that description in version control and let the system converge towards it. The idea was powerful because it changed both the mechanism and the team workflow.
Configuration could be reviewed. A change could be repeated. Drift could be identified. Rebuilding became less frightening because the important knowledge was no longer trapped inside the existing machine.
The panel question behind the tool
The interesting question was not “Is Puppet good?” It was how configuration management was changing the industry and what would come next.
Even then, the tool choice was only part of the answer. Teams had to decide who owned the modules, how changes were tested, how secrets were handled, what happened when convergence failed and how much variation should be allowed between services.
Those are recognisable platform engineering questions today.
What changed after 2015
The unit of operation moved. Many teams stopped treating a long-lived virtual machine as the primary deployment target. Containers made application dependencies more portable. Kubernetes introduced a larger reconciliation system. Cloud APIs made infrastructure programmable. GitOps brought the version-controlled desired-state model into continuous delivery.
The configuration surface also became much larger. A team may now manage cloud accounts, clusters, controllers, policies, service meshes, secrets, deployment manifests and application configuration—each with its own reconciliation loop.
That is an enormous increase in leverage, but also an increase in the number of ways automation can interact unexpectedly.
What did not change
Several principles from configuration management still hold:
- Desired state needs feedback. Declaring an outcome is not enough; teams need to know whether the system converged and why it did not.
- Idempotency creates confidence. Repeating an operation should move the system towards the same result rather than compound accidental change.
- Version control provides history, not understanding. A commit explains what changed; good context explains why.
- Defaults are product decisions. A module, Helm chart or platform API encodes an opinion about how teams should work.
- Escape hatches need design. A standard path creates leverage only while teams have a deliberate way to handle valid exceptions.
- Automation can spread mistakes faster. Review, progressive delivery and observability matter more as the blast radius grows.
From configuration management to platform engineering
The journey from Puppet to Kubernetes was not a clean replacement. It was an expansion of the same ambition: make complex operational work reproducible and safe enough that it does not depend on heroics.
Modern internal platforms add another requirement. The desired state must be valuable to the engineers consuming it. A perfectly reconciled platform that creates queues, hides failures or forces every workload through the wrong abstraction has automated the system without improving the experience.
That is the part of the 2015 conversation I appreciate more now. Configuration management was never only about managing files on servers. It was an early language for discussing trust in automation—and that discussion is nowhere near finished.