Infrastructure as code, from home-grown scripts to industrialized self-service
While the origins of infrastructure as code (IaC) can be traced back to very early configuration management tools, the concept really took the shape it has today with the emergence of the cloud. Engineering teams had to face unprecedented scaling challenges. Over the past two decades, it has evolved rapidly, staying in step with new technology approaches and organizational needs.
Few professionals are better placed to speak to these shifts than Kief Morris, Adservio expert. In 2016, he literally wrote the reference book on the subject for O'Reilly. Nearly a decade later, he's publishing a third edition of his work. We caught up with him to understand how infrastructure has evolved in recent years and to explain why a new edition was needed in 2025.
Why a third edition changed the game
Application-driven workflows
Michel S.: Why a third edition of Infrastructure as Code? What was missing? What was left to say?
Kief Morris: Infrastructure automation has evolved considerably in the five years since the second edition came out. There's a growing need to understand the business outcomes infrastructure needs to support, rather than designing from a purely technological perspective. There's growing interest in approaches that offer self-service infrastructure provisioning to development teams, as part of platform engineering strategies. The third edition builds on the infrastructure design patterns described in the first two editions, adding guidance for creating infrastructure components that can be built, delivered, deployed, and configured as part of application-driven workflows.
The growing weight of automated deployment
Related to making infrastructure easier for software teams to consume, we've seen growth in infrastructure deployment techniques and tools in recent years. This edition therefore includes more content on automated infrastructure delivery services and team workflows, reusable component catalogs, internal resource-request portals, and tighter integration between application code and the infrastructure code that carries it.
The persistent gap between market tooling and real needs
The legacy model: specialists versus siloed developers
MS: Were you surprised by how the infrastructure-as-code space has evolved over the nine years since you wrote your first book?
KM: I'm somewhat disappointed that most tool and technology vendors haven't moved past legacy mental models around building and managing infrastructure. Most tools and services meant to help infrastructure teams still encourage workflows where infrastructure specialists manually define and provision infrastructure for siloed developers.
The symptoms: handoffs, snowflake environments, bottlenecks
We still run into handoffs, heavily customized "snowflake code" environments, and infrastructure becoming a bottleneck for delivery. In practice, this shows up as request tickets piling up, staging environments silently drifting away from production, and application teams bypassing the official process with manual changes in the cloud console, recreating exactly the mess infrastructure as code was supposed to eliminate.
Have the core skills actually changed?
MS: How have the skills needed to tackle infrastructure-as-code challenges evolved?
KM: I'm not sure the core skills have changed much in recent years. There are more cloud services and technologies to keep up with. Container orchestration ("cloud native") is at the heart of most platforms these days. But the fundamental principles still hold.
More cloud services to track, principles that still hold up
What's genuinely changing is the volume: a platform team now has to arbitrate between dozens of managed services, multiple cloud providers in multi-cloud organizations, and extra abstraction layers such as shared modules or internal platform components. The design skill, knowing how to break a system into coherent, versioned, testable components, nonetheless remains the same one that already had to be mastered a decade ago.
Container orchestration at the heart of today's platforms
The rise of Internal Developer Platforms built on top of container orchestration has changed how teams consume infrastructure, without changing the nature of the problem being solved: offering safe, reproducible paved paths, rather than total freedom with no safety net.
Staying tool-agnostic amid a proliferation of tools
MS: Is it hard to give advice given such a diversity of tools and possible approaches? As an author and advisor, how easy is it to stay tool-agnostic?
KM: I focus my attention on the principles, practices, and patterns that apply across tools and platforms. I find some people ask for code examples, but my experience shows that providing examples puts readers off when the examples use a language or cloud different from their own.
Transferable principles over fixed recipes
When I explain a concept that benefits from a code-level example, I use pseudo-code to make it accessible to the widest range of users. However, most of my examples and illustrations sit at the design level and can be implemented in pretty much any tool.
One very concrete problem: managing shared state and configuration
This search for transferable principles sometimes runs into implementation details that vary enormously from one tool to another, how to manage infrastructure state shared across multiple teams or environments is a good example, with very different approaches depending on the chosen tool and classic pitfalls that recur from one organization to the next.
Day-two requirements: the real challenge of modern infrastructure
MS: You talked about day-two requirements in an interview given to a technical podcast with Ken Mugrage. Can you explain what that is and why it matters now?
KM: Most infrastructure-as-code guidance focuses on designing and building new infrastructure. But where most teams run into difficulty is managing and maintaining infrastructure over the long term. How do you make sure that as your systems grow, each new environment isn't built differently from older ones, to avoid creating a mess of different versions and configurations? How do you update older environments? How do you make changes to infrastructure in production?
Consolidating, cleaning up, controlling costs
This matters because the problem teams face today is less about migrating to the cloud for the first time. Teams need to consolidate and clean up chaotic messes, control costs, avoid accumulating technical debt in their environments, and keep up with evolving technology. Drift detection between the state declared in code and the actual state observed in the cloud, long treated as a secondary concern, has become as central a building block as initial provisioning.
Evolving production infrastructure without breaking everything
Evolving live infrastructure requires guardrails that the initial design often overlooks: policy as code to block risky changes before they reach production, GitOps-style continuous reconciliation loops to automatically pull the actual state back toward the desired state, and pipelines able to detect and self-correct certain classes of drift without waiting for human intervention.
Toward good infrastructure: what we still don't know
MS: You also said on the Technology Podcast: "we humans don't yet know what good infrastructure looks like." Do you think we ever will?
KM: Of course, we have to! I think with many new technologies, it takes several generations to stop reproducing the approaches we used with older technologies and to discover how to fully take advantage of the opportunities new technologies offer.
Several generations to change mental software
This pattern holds at every technology leap: the first generations of cloud systems initially reproduced physical-datacenter habits, individually named servers, manual changes documented after the fact, before infrastructure as code imposed a new discipline. The current generation is reproducing, with internal platforms and container orchestration, some of the reflexes inherited from infrastructure as code itself, before finding its own balance.
Platform engineering as the next step
That is precisely the role of platform engineering: to speed up this maturing process. By turning infrastructure into an internal product consumed via self-service rather than a ticket-based service, it forces organizations to make explicit what they consider "good" infrastructure, secure by default, observable, easily recoverable, instead of discovering it by accident through incidents.
Conclusion: what stays the same, what changes
Thanks to Kief for his time. What stands out from this exchange is a reassuring kind of stability amid an ever-shifting tooling landscape: the design principles of infrastructure as code have barely changed in a decade, but their implementation has moved from the individual script to the platform product, and the center of gravity of the work has shifted from initial construction to day-two maintenance. You can learn more by listening to Kief on a well-known technical podcast or by exploring his book, you'll find a free chapter on the book's page on this site.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect Adservio's positions.
STAY POSTED
Get our next analyses and field notes straight to your inbox.
