# Infrastructure as Code: Where Are We Today? > An interview with Adservio expert Kief Morris on the evolution of infrastructure as code: platform, self-service, and day-two challenges in 2026. - Date : 2025-08-26 - Lecture : 8 min - Catégorie : devsecops - Tags : AI, DevOps, Cloud, Automation - URL : https://www.adservio.fr/en/insights/articles/infrastructure-en-tant-que-code-ou-en-sommes-nous-aujourd ## TL;DR - Infrastructure as code (IaC) took its current shape with the rise of the cloud, as engineering teams faced unprecedented scaling challenges. - Kief Morris, Adservio expert and author of the reference book on IaC for O'Reilly, is publishing a third edition focused on business outcomes and self-service infrastructure through platform engineering. - Most tools on the market remain stuck on legacy mental models, where infrastructure specialists manually provision infrastructure for siloed developers, producing handoffs and heavily customized "snowflake" environments. - The real challenge today is no longer the initial cloud migration but "day-two requirements": maintaining, evolving, and cleaning up existing infrastructure without accumulating technical debt and inconsistencies across environments. - The fundamentals of IaC remain stable over time; what's changing is the sheer volume of cloud services, the growing weight of container orchestration, and the rising maturity of platform engineering. ## 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. > Related read: [How Terraform's Partial Backend Configuration Enables Infrastructure Automation at Scale](https://www.adservio.fr/en/insights/articles/comment-la-configuration-backend-partielle-de-terraform): Terraform partial backend configuration: separate static from dynamic settings to eliminate duplication, secure secrets and deploy at enterprise scale. ## 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. > Related read: [Self-healing CI/CD pipelines: self-repair through AI](https://www.adservio.fr/en/insights/articles/pipelines-cicd-auto-reparants-self-healing): Self-healing CI/CD pipelines in 2026: how LLM agents and Kubernetes operators detect, diagnose and fix delivery failures, with guardrails and measurable FinOps gains. ## 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. > Related read: [The evolution of platform engineering](https://www.adservio.fr/en/insights/articles/l-evolution-de-l-ingenierie-de-plateforme): Seven years from DevOps to platform engineering: from manual deployments to product-minded IDPs, SLOs, and AI-infused platforms in 2026. ## 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. ## FAQ ### Why a third edition of the infrastructure-as-code book? Because infrastructure automation has evolved a great deal since the second edition: a growing need to connect infrastructure to business outcomes, the rise of self-service for development teams through platform engineering, and more deployment automation techniques, tools, and application-driven workflows. ### What are "day-two requirements" in infrastructure as code? These are the challenges of managing and maintaining infrastructure over the long term, once it's already built: keeping each new environment from drifting away from earlier ones, detecting and fixing drift between declared and actual state, updating existing environments, and applying production changes without creating inconsistencies or technical debt. ### Have the skills needed for IaC changed much in recent years? According to Kief Morris, the core principles remain largely stable. What's changing is the number of cloud services and technologies to keep up with, with container orchestration and internal developer platforms now central to most current organizations.