I began working as a systems administrator in a team that managed Unix servers and workstations at the Computer Science department of the University of Tennessee. From then, into the dot-com days and after, I’ve been drawn to applying what I learned about software development to automate managing servers and other infrastructure.
I discovered the Infrastructures.org website in 2001,1 which was an eye-opener. The authors introduced me to Mark Burgess' pioneering infrastructure tool CFEngine and the value of automatically provisioning servers in a consistent, repeatable way, something I used to build physical servers in data centers for a series of startup and scale-up companies in the 2000s.
Infrastructure as Code, as a term, appeared around the same time that Andrew Clay Shafer and Patrick Debois kicked off the DevOps movement with a talk at the Agile 2008 conference. The first uses I’ve found for the term “Infrastructure as Code” are from a talk called “Agile Infrastructure” that Shafer gave at the Velocity conference in 2009 and an article John Willis wrote summarizing the talk. Adam Jacob, who cofounded Chef, and Luke Kanies, founder of Puppet, also used the term around this time.
Infrastructure as Code tools create the opportunity to work in ways that help you to deliver changes more frequently, quickly, and reliably, improving the overall quality of your systems. But the benefits don’t come from the tools themselves. They come from the way you use them. Innovators are creating new tools and techniques for building and managing infrastructure using code, as well as potential new generations of tools that move beyond the “as code” paradigm. Whatever tools we use, the trick is to leverage the technology to embed quality, reliability, and compliance into the process of making changes.
As cloud computing and Infrastructure as Code grew from a niche into the mainstream in the 2010s, I learned how to put Infrastructure as Code into practice by reading blog posts, attending talks, and working with various tools with consulting clients. I waited for one of the DevOps luminaries I admired to write a book I could share as a comprehensive collection of guidance for this practice. By the middle of the decade, they had yet to write it, so I outlined my ideas for what they should write, carried on fleshing it out, and ended up with the first edition of this book in 2016.
The first edition focused on server configuration using tools like Chef and Puppet. The second edition in 2020 shifted to infrastructure “stacks” using tools like Amazon Web Services (AWS) Cloud Development Kit (CDK) and Terraform, with more interest in cloud native application runtimes like container clusters and serverless.
With this third edition, the shift to using infrastructure code to provide application runtimes based on containers and serverless over configuring server images is much further along. More people are interested in coding infrastructure using general-purpose languages, as enabled by CDK and Pulumi, and are curious about shifting to integrating application and infrastructure code.
As infrastructure engineers and architects, we need to know how infrastructure enables value for the organization. We must move beyond infrastructure spaghetti code that creates a sprawl of unmanageable environments. This edition shares emerging patterns and practices for a more componentized, composable approach to Infrastructure as Code.
In this book I share approaches that are widely used today, but I don’t believe we’re anywhere near the end of the journey of finding better ways to manage digital infrastructure. I hope this edition will help you manage your infrastructure more effectively. And I also hope it will inspire you to push beyond current practices. We may eventually move beyond using code to define infrastructure. But whatever specific tools we use, I believe that thoughtful use of effective software design principles and techniques can help us do better, and I hope this new edition will help.
This book’s thesis is that practices, patterns, and techniques can be applied across infrastructure platforms using various infrastructure tools. It focuses less on specific tools and more on how to use them. Although I discuss available tools, you won’t find details of how to work with any particular one. You will find patterns, practices, and techniques that should be relevant to whatever tools and platforms you use.
You won’t find many code examples for real-world tools or clouds. Tools change too quickly in this field to keep code examples accurate. The advice in this book should age more slowly and be applicable across tools. Instead, I write pseudocode examples for fictional tools to illustrate concepts.
Too many topics fall under the label “infrastructure” for this book to cover. So I’ve kept the scope focused on using code to manage infrastructure as a service (IaaS) cloud infrastructure, leaving subjects like engineering platforms, developer portals, site reliability engineering (SRE), observability, container orchestration, and AI for other books and resources.
This book is for people involved in providing and using infrastructure to deliver and run software. You may have a background in systems and infrastructure or software development and delivery. Your role may be engineering, testing, architecture, or management. I assume you have some exposure to cloud infrastructure and infrastructure automation tools.
Readers new to Infrastructure as Code should find this book a good introduction to the topic. However, you will get the most out of it if you know how infrastructure cloud platforms work, and the basics of at least one infrastructure coding tool. I suggest complementing this book with learning resources for the specific cloud platforms and Infrastructure as Code tools you use.
Those with more experience working with these tools should find a mixture of familiar and new concepts and approaches. The content should create a common language and articulate challenges and solutions in ways that experienced practitioners and teams find helpful.
I use the terms principles, practices, and patterns (and antipatterns) to describe essential concepts. Here are the ways I use each of these terms:
A principle is a rule that helps you choose between potential solutions.
A practice is a way of implementing something. A given practice is not always the only way to do something and may not be the best way to do it for a particular situation. You should use principles to guide you in choosing the most appropriate practice for a given situation.
A pattern is a potential solution to a problem. It is similar to a practice in that different patterns may be more effective in different contexts. Each pattern is described in a format that should help you evaluate its relevance for your problem.
An antipattern is a potential solution that you should avoid in most situations. It usually seems like a good idea or is something that you fall into doing without realizing it.
Folks in our industry love to talk about “best practices.” However, this term often leads people to think there is only one solution to a problem, no matter the context.
I prefer to describe practices and patterns and note when they are helpful along with their limitations. I describe some of these as more effective or appropriate while staying open to alternatives, and I explain why some practices are less effective.
I use a fictional company called FoodSpin to illustrate concepts throughout this book. FoodSpin is a digital service that allows restaurants to provide searchable menus for customers to order and pay for their meals. “Introduction to FoodSpin and Its Strategy” gives a high-level view of the company’s strategy. I use FoodSpin’s team workloads and infrastructure estate to illustrate design patterns and implementation techniques.
Many of my code examples use fictitious IaaS platforms, infrastructure tools, and pseudocode whose syntax may vary from example to example, depending on my point. I intend to illustrate concepts that apply across technology stacks.
See the book’s companion website and subscribe to the newsletter.
The following typographical conventions are used in this book:
Indicates new terms, URLs, email addresses, filenames, and file extensions.
Constant widthUsed for program listings, as well as within paragraphs to refer to program elements such as variable or function names, databases, data types, environment variables, statements, and keywords.
Constant width boldShows commands or other text that should be typed literally by the user.
Constant width italicShows text that should be replaced with user-supplied values or by values determined by context.
This element signifies a tip or suggestion.
This element signifies a general note.
This element indicates a warning or caution.
For more than 40 years, O’Reilly Media has provided technology and business training, knowledge, and insight to help companies succeed.
Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, visit http://oreilly.com.
Please address comments and questions concerning this book to the publisher:
We have a web page for this book, where we list errata, examples, and any additional information. You can access this page at https://oreil.ly/infrastructure-as-code-3e.
For news and information about our books and courses, visit https://oreilly.com.
Find us on LinkedIn: https://linkedin.com/company/oreilly-media.
Watch us on YouTube: https://youtube.com/oreillymedia.
I assumed that updating from the second edition of this book to the third would be much easier than it was, or at least less work than writing the first two editions. On the contrary, it was a huge effort. Fortunately, as with the earlier editions, I’ve had a wealth of support from many people.
I owe a great deal to my colleagues, clients, and former colleagues from Thoughtworks. I doubt I would have written this book without the years of immersion in that community of people dedicated to improving our industry and society. I’ve learned from, been inspired by, and benefited from the advice and feedback from members of Thoughtworks’ internal communities, project teams, and growing network of alumni.
I’ve tried to keep track of the people who’ve given me feedback, ideas, and notable support, but I’m sure I’ve missed many of them. My incomplete list includes Adam Jacob, Brian Grant, Cat Morris, Chris Roberts, Clare Walkley, Dale Peakall, Fergus Orbach, Kai Hendry, Kamesh Marthy, Kjeld Schmidt, Manuel Pais, Matthew Skelton, Mohamed Abbas, Monish Jain, Paul Stack, Reinaldo de Souza, Thien-An Mac, Tiago Lock, and Vincenzo Fabrizi.
A number of people gave me their notes on drafts of this book, including Abby Bangser, Alexis Richardson, Claire Walkley, Gregor Hohpe, Marc Hofer, Mike Roberts, and Wisen Tanasa. Thanks to my technical reviewers: Chris Devers, Doron Beit-Halahmi, Lipi Deepaakshi Patnaik, Mary Branscombe, Robert Quinlivan, Simon Bisson, Thierry de Pauw, and Yevgeniy (Jim) Brikman.
I’ve benefited from John Devin’s support at O’Reilly over the years. My editor, Jill Leonard, provided not only her invaluable advice and guidance throughout the process of working on this edition, but also her patience and calm assurance that kept me going when it all felt like a slog.
Last and most, everlasting love to Ozlem, Erel, Jax, and Theo, who endured my obsession with this book. Yet again.
1 The original content remains on this site as of January 2025, although it hasn’t been updated since 2007.