Infrastructure as Code • Kief Morris & Abby Bangser

In a conversation with Abby Bangser, Kief Morris reflects on the decade since the first edition of his book, “Infrastructure as Code,” charting the evolution of the practice and looking toward its future.

The Evolution of Infrastructure as Code (IaC)

A decade ago, the focus of IaC was primarily on server configuration management, with tools like Chef and Puppet dominating the landscape. The conversation has since shifted dramatically with the rise of cloud platforms, containerization, and serverless architectures. This has led to an explosion in the complexity and scale of what is being built.

The core change has been the move up the stack in abstraction layers:

• From Physical to Virtual: Virtualization allowed engineers to worry less about “the tin and the wires” and more about the conceptual virtual server.
• From Servers to Containers: Containerization abstracted away the underlying host, focusing on the application image.
• From Containers to Serverless: Serverless architectures further abstract the execution environment, often removing the container from the developer’s direct concern.

This layering has created a “big mess” of complexity, leading to questions about whether current IaC practices and tools are still sufficient.

Current Challenges: Abstraction and Tooling

While the principles of IaC have adapted, the tooling often struggles with modern complexity. A key challenge is that many IaC tools, like Terraform, function as thin wrappers over low-level cloud APIs. This forces engineers to work with primitive components like EC2 instances and subnets, making it difficult to manage the cognitive load.

Infrastrucure code when you look at it, it’s really like a thin wrapper over the APIs of these clouds… the things that you you define in terraform are just like, well, there’s an EC2 instance, there’s a subnet, there’s this… it is super low-level stuff and it’s just getting harder and harder to work at that level.

This leads to what Morris calls “snowflakes as code”: environments are defined in code, but creating a new environment often involves copying the code and tweaking it, resulting in maintenance overhead for multiple, static, low-level definitions.

The Need for Better Abstractions

The core issue is not necessarily the language (declarative vs. imperative) but the level of abstraction. A developer shouldn’t need to wire up low-level networking just to expose an application. They should be able to declare their intent, such as, “I need a secure connection from the internet.”

However, abstractions shouldn’t completely hide the underlying layers. Citing Martin Thompson’s concept of “mechanical sympathy,” Morris argues that engineers need the ability to “thunk down” and inspect lower levels to troubleshoot issues like performance problems. The goal of abstraction is to manage cognitive scope, allowing focus on the immediate problem without being overwhelmed, while retaining access to the details when necessary. This aligns with the platform engineering concept of “progressive discovery.”

The Future of Infrastructure Management

Several new approaches are emerging to address the limitations of current IaC tools.

• Emerging Tools: Projects like System Initiative (from the founder of Chef) are rethinking the foundation of IaC. Instead of focusing on code files in Git, they focus on directly manipulating the data structures that represent the infrastructure’s state. While the user interface might be graphical, the underlying innovation is in the data-centric model, which could resolve some of the reconciliation challenges found in statefile-based tools.
• Applying Software Engineering Principles: The infrastructure domain can learn a great deal from established software architecture and delivery practices.
  • Domain-Driven Design (DDD): Infrastructure should be modeled starting from the application’s needs (“application-driven development”). The business domain model can be extended downward to technical capability domains like monitoring, storage, and security.
  • Microservices Principles: Instead of monolithic IaC projects that can take hours to apply, the industry should move toward smaller, more tractable, and independently deployable units of infrastructure. This improves feedback cycles and enables better automated testing and pipeline integration.

The Role of AI

Artificial intelligence presents both opportunities and risks for infrastructure management. A naive approach of using a chatbot to provision resources risks creating “AI-assisted click-ops,” repeating the mistakes of the past.

A more valuable application would be to use AI as a “coach.” For instance, when a developer needs a database, an AI assistant could ask targeted questions about the data type, compliance requirements (e.g., PII), durability, and transactionality. It could even analyze the application’s codebase to make intelligent recommendations, guiding the developer to select and configure the right pre-built, compliant components.

Connecting Infrastructure to Business Value

Ultimately, the conversation highlights that infrastructure is not just generic “plumbing.” The belief that infrastructure can be a simple utility that the business doesn’t need to think about is a fallacy. The true utility layer is provided by the cloud platforms (AWS, Azure, etc.).

The layer built on top of the cloud—the internal platform—is not generic. It must be tailored to the specific needs of the business, its domains, and its compliance landscape. This is the core challenge that Platform Engineering and the focus on Developer Experience (DevEx) aim to solve. Effective infrastructure requires a conscious effort to connect business value all the way down to technical decisions, demanding collaboration between business, development, and operations teams.

• Tags:
• AI
• Devops
• Platform Engineering
• Cloud Architecture
• Infrastructure as Code
• System Initiative
• Terraform
• Abstraction