Infrastructure as code: Where are we today?

Although the genealogy of infrastructure as code (IaC) can be traced back to very early configuration management tools, the concept only really took the form it has today with the emergence of cloud, as engineering teams had to grapple with scale in ways they previously had not. In the couple of decades since it has evolved rapidly, keeping pace with both new technological thinking and organizational needs. 

Few people are better placed to talk about these changes in infrastructure as code than Thoughtworker Kief Morris. Back in 2016 he quite literally wrote the book on it for O'Reilly. And now, almost a decade later, he has released a third edition of the book. We caught up with him to get his thoughts on how infrastructure has changed in recent years and to explain why a new edition of his book was needed in 2025.

Richard Gall: Why a third edition of Infrastructure as Code? What was missing? What needed to be said?

Kief Morris: Infrastructure automation has evolved in the five years since the second edition came out. There's even more need to understand the business outcomes that infrastructure needs to support, rather than designing from a technology-led perspective.

There's increasing interest in ways to provide self-service infrastructure provisioning for development teams as part of platform engineering strategies. So, the third edition builds on the infrastructure design patterns described the first two editions, adding guidance for making infrastrucure components that can be built, delivered, deployed and configured as part of application-drive workflows.

Related to making infrastructure easier for software teams to consume is the growth of infrastructure deployment techniques and tooling over the past few years. So this edition includes more on automated infrastructure deployment services and team workflows.

RG: Has anything surprised you about how the infrastructure as code space has evolved in the nine years since you first wrote the book?

KM: I'm a bit disappointed that not many tool and technology vendors have moved beyond legacy mental models for building and managing infrastructure. Most tools and services aimed at helping infrastructure teams still encourage workflows where infrastructure specialists manually define and provision infrastructure for developers in a silo. So we still get handovers, heavily customized "snowflakes as code" environments and infrastructure as a bottleneck for delivery.

RG: How have the skills needed to tackle infrastructure (as code) challenges changed?

KM: I'm not sure the core skills have changed all that much in the past few years. There are more cloud services and technologies to keep track of. Container orchestration ("cloud native") is at the core of most platforms these days. But the fundamentals still apply.

RG: Is it difficult to offer advice when there’s such diverse tooling and different potential approaches? How easy is it, as an author and advisor, to be tool agnostic?

KM: I keep my focus on principles, practices, and patterns that apply across tools and platforms. I do find that some people ask for code examples, but my experience is that providing those turns people off when the examples use a different language or cloud than the one the reader uses.

Where I explain a concept that benefits from a code-level example, I use pseudo-code to keep it accessible to the widest range of users. But most of my examples and illustrations are at the design level, and could be implemented in pretty much any tool.

RG: On the Technology Podcast with Ken Mugrage you talked about day two requirements — could you explain what these are and why they matter now?

KM: Much advice around infrastructure as code focuses on designing and building new infrastructure. But where most teams struggle is managing and maintaining infrastructure over the longer term. How do you make sure that, as your systems grow, each new environment isn't built differently from older environments, to avoid creating a mess of different versions and configurations? How do you update older environments? How do you make changes to live infrastructure?

This matters because the problem people are facing these days is less about moving to the cloud for the first time. Teams need to consolidate and clean up sprawling spaghetti messes, get costs under control, avoid accumulating technical debt in their environments and keep up with changing technologies.

RG: Also on the Technology Podcast you said “we humans don't know what good looks like with infrastructure yet.” Do you think we ever will? 

KM: Sure, we have to! I think with many new technologies it takes a few generations to stop replicating the approaches we used with older technologies and figure out how to take full advantage of the opportunities that the new technologies provide.

Thanks Kief for taking the time to speak.

You can learn more by listening to Kief on the Thoughtworks Technology Podcast or by diving into his book — you'll find a free chapter on the book's page on this website.