Praise for Infrastructure as Code
Infrastructure as Code practices have evolved from managing servers to managing complete stacks, but this new power comes at the cost of complexity. This book will take you beyond the commands to the design patterns behind good practices and the how-tos of next-level automation .
Patrick Debois, DevOpsDays Founder
Infrastructure as Code sits at the intersection of multiple software engineering domains. This book regroups and distills the relevant best practices from each domain to give readers an accelerated course on infrastructure automation.
Carlos Cond, VP of Engineering at Sweetgreen
A down-to-earth guide for navigating the landscape of cloud infrastructure with principles, practices and patterns .
Effy Elden, Technologist at ThoughtWorks
Infrastructure as Code
by Kief Morris
Copyright 2021 Kief Morris. All rights reserved.
Printed in the United States of America.
Published by OReilly Media, Inc. , 1005 Gravenstein Highway North, Sebastopol, CA 95472.
OReilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com .
Acquisitions Editor: John Devins | Indexer: Potomac Indexing, LLC |
Development Editor: Virginia Wilson | Interior Designer: David Futato |
Production Editor: Kate Galloway | Cover Designer: Karen Montgomery |
Copyeditor: Kim Cofer | Illustrator: John Francis Amalanathan |
Proofreader: nSight, Inc. |
- June 2016: First Edition
- December 2020: Second Edition
Revision History for the Second Edition
- 2020-11-17: First Release
See http://oreilly.com/catalog/errata.csp?isbn=9781098114671 for release details.
The OReilly logo is a registered trademark of OReilly Media, Inc. Infrastructure as Code, the cover image, and related trade dress are trademarks of OReilly Media, Inc.
While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.
This work is part of a collaboration between OReilly and Linode. See our statement of editorial independence.
978-1-098-11467-1
[GP]
Preface
Ten years ago, a CIO at a global bank scoffed when I suggested they look into private cloud technologies and infrastructure automation tooling: That kind of thing might be fine for startups, but were too large and our requirements are too complex. Even a few years ago, many enterprises considered using public clouds to be out of the question.
The capabilities that these platforms offer are evolving and improving so quickly that its hard to ignore them without risking obsolescence.
Cloud and automation technologies remove barriers to making changes to production systems, and this creates new challenges. While most organizations want to speed up their pace of change, they cant afford to ignore risks and the need for governance. Traditional processes and techniques for changing infrastructure safely are not designed to cope with a rapid pace of change. These ways of working tend to throttle the benefits of modern, Cloud Age technologiesslowing work down and harming stability.
In ) to describe the different philosophies that apply to managing physical infrastructure, where mistakes are slow and costly to correct, and managing virtual infrastructure, where mistakes can be quickly detected and fixed.
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 dont come from the tools themselves. They come from how you use them. The trick is to leverage the technology to embed quality, reliability, and compliance into the process of making changes.
Why I Wrote This Book
I wrote the first edition of this book because I didnt see a cohesive collection of guidance on how to manage Infrastructure as Code. There was plenty of advice scattered across blog posts, conference talks, and documentation for products and projects. But a practitioner needed to sift through everything and piece a strategy together for themselves, and most people simply didnt have time.
The experience of writing the first edition was amazing. It gave me the opportunity to travel and to talk with people around the world about their own experiences. These conversations gave me new insights and exposed me to new challenges. I learned that the value of writing a book, speaking at conferences, and consulting with clients is that it fosters conversations. As an industry, we are still gathering, sharing, and evolving our ideas for managing Infrastructure as Code.
Whats New and Different in This Edition
Things have moved along since the first edition came out in June 2016. That edition was subtitled Managing Servers in the Cloud, which reflected the fact that most infrastructure automation until that point had been focused on configuring servers. Since then, containers and clusters have become a much bigger deal, and the infrastructure action has moved to managing collections of infrastructure resources provisioned from cloud platformswhat I call stacks in this book.
As a result, this edition involves more coverage of building stacks, which is the remit of tools like CloudFormation and Terraform. The view Ive taken is that we use stack management tools to assemble collections of infrastructure that provide application runtime environments. Those runtime environments may include servers, clusters, and serverless execution environments.
Ive changed quite a bit based on what Ive learned about the evolving challenges and needs of teams building infrastructure. As Ive already touched on in this preface, I see making it safe and easy to change infrastructure as the key benefit of Infrastructure as Code. I believe people underestimate the importance of this by thinking that infrastructure is something you build and forget.
But too many teams I meet struggle to meet the needs of their organizations; they are not able to expand and scale quickly enough, support the pace of software delivery, or provide the reliability and security expected. And when we dig into the details of their challenges, its that they are overwhelmed by the need to update, fix, and improve their systems. So Ive doubled down on this as the core theme of this book.
This edition introduces three core practices for using Infrastructure as Code to make changes safely and easily:
Define everything as code
This one is obvious from the name, and creates repeatability and consistency.
Continuously test and deliver all work in progress
Each change enhances safety. It also makes it possible to move faster and with more confidence.
Build small, simple pieces that you can change independently