Infrastructure as Code Dynamic Systems for the Cloud Age (Kief Morris) (Z-Library)

Kief Morris Second Edition Infrastructure as Code Dynamic Systems for the Cloud Age

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-to’s 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

Kief Morris Infrastructure as Code Dynamic Systems for the Cloud Age SECOND EDITION Boston Farnham Sebastopol TokyoBeijing

978-1-098-11467-1 [GP] Infrastructure as Code by Kief Morris Copyright © 2021 Kief Morris. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly 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/institu‐ tional 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 2021-01-15: Second Release See http://oreilly.com/catalog/errata.csp?isbn=9781098114671 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Infrastructure as Code, the cover image, and related trade dress are trademarks of O’Reilly 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 O’Reilly and Linode. See our statement of editorial inde‐ pendence.

Table of Contents Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv Part I. Foundations 1. What Is Infrastructure as Code?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 From the Iron Age to the Cloud Age 2 Infrastructure as Code 4 Benefits of Infrastructure as Code 4 Use Infrastructure as Code to Optimize for Change 4 Objection: “We don’t make changes often enough to justify automating them” 5 Objection: “We should build first and automate later” 6 Objection: “We must choose between speed and quality” 7 The Four Key Metrics 9 Three Core Practices for Infrastructure as Code 9 Core Practice: Define Everything as Code 10 Core Practice: Continuously Test and Deliver All Work in Progress 10 Core Practice: Build Small, Simple Pieces That You Can Change Independently 11 Conclusion 11 2. Principles of Cloud Age Infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Principle: Assume Systems Are Unreliable 14 Principle: Make Everything Reproducible 14 Pitfall: Snowflake Systems 15 Principle: Create Disposable Things 16 Principle: Minimize Variation 17 v

Configuration Drift 17 Principle: Ensure That You Can Repeat Any Process 20 Conclusion 21 3. Infrastructure Platforms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 The Parts of an Infrastructure System 23 Infrastructure Platforms 25 Infrastructure Resources 27 Compute Resources 28 Storage Resources 29 Network Resources 31 Conclusion 33 4. Core Practice: Define Everything as Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Why You Should Define Your Infrastructure as Code 35 What You Can Define as Code 36 Choose Tools with Externalized Configuration 36 Manage Your Code in a Version Control System 37 Infrastructure Coding Languages 38 Infrastructure Scripting 39 Declarative Infrastructure Languages 41 Programmable, Imperative Infrastructure Languages 43 Declarative Versus Imperative Languages for Infrastructure 44 Domain-Specific Infrastructure Languages 44 General-Purpose Languages Versus DSLs for Infrastructure 46 Implementation Principles for Defining Infrastructure as Code 46 Separate Declarative and Imperative Code 46 Treat Infrastructure Code Like Real Code 47 Conclusion 48 Part II. Working with Infrastructure Stacks 5. Building Infrastructure Stacks as Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 What Is an Infrastructure Stack? 51 Stack Code 53 Stack Instance 53 Configuring Servers in a Stack 54 Low-Level Infrastructure Languages 54 High-Level Infrastructure Languages 55 Patterns and Antipatterns for Structuring Stacks 56 Antipattern: Monolithic Stack 56 vi | Table of Contents

Pattern: Application Group Stack 59 Pattern: Service Stack 60 Pattern: Micro Stack 62 Conclusion 63 6. Building Environments with Stacks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 What Environments Are All About 65 Delivery Environments 66 Multiple Production Environments 66 Environments, Consistency, and Configuration 67 Patterns for Building Environments 68 Antipattern: Multiple-Environment Stack 68 Antipattern: Copy-Paste Environments 70 Pattern: Reusable Stack 72 Building Environments with Multiple Stacks 74 Conclusion 75 7. Configuring Stack Instances. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Using Stack Parameters to Create Unique Identifiers 79 Example Stack Parameters 79 Patterns for Configuring Stacks 80 Antipattern: Manual Stack Parameters 81 Pattern: Stack Environment Variables 82 Pattern: Scripted Parameters 84 Pattern: Stack Configuration Files 87 Pattern: Wrapper Stack 90 Pattern: Pipeline Stack Parameters 93 Pattern: Stack Parameter Registry 96 Configuration Registry 99 Implementing a Configuration Registry 100 Single or Multiple Configuration Registries 102 Handling Secrets as Parameters 102 Encrypting Secrets 102 Secretless Authorization 103 Injecting Secrets at Runtime 103 Disposable Secrets 104 Conclusion 104 8. Core Practice: Continuously Test and Deliver. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Why Continuously Test Infrastructure Code? 106 What Continuous Testing Means 106 What Should We Test with Infrastructure? 108 Table of Contents | vii

Challenges with Testing Infrastructure Code 110 Challenge: Tests for Declarative Code Often Have Low Value 110 Challenge: Testing Infrastructure Code Is Slow 113 Challenge: Dependencies Complicate Testing Infrastructure 114 Progressive Testing 115 Test Pyramid 116 Swiss Cheese Testing Model 118 Infrastructure Delivery Pipelines 119 Pipeline Stages 120 Scope of Components Tested in a Stage 121 Scope of Dependencies Used for a Stage 121 Platform Elements Needed for a Stage 122 Delivery Pipeline Software and Services 123 Testing in Production 125 What You Can’t Replicate Outside Production 125 Managing the Risks of Testing in Production 126 Conclusion 127 9. Testing Infrastructure Stacks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Example Infrastructure 129 The Example Stack 130 Pipeline for the Example Stack 131 Offline Testing Stages for Stacks 131 Syntax Checking 132 Offline Static Code Analysis 132 Static Code Analysis with API 133 Testing with a Mock API 133 Online Testing Stages for Stacks 134 Preview: Seeing What Changes Will Be Made 134 Verification: Making Assertions About Infrastructure Resources 135 Outcomes: Proving Infrastructure Works Correctly 137 Using Test Fixtures to Handle Dependencies 137 Test Doubles for Upstream Dependencies 139 Test Fixtures for Downstream Dependencies 139 Refactor Components So They Can Be Isolated 141 Life Cycle Patterns for Test Instances of Stacks 142 Pattern: Persistent Test Stack 142 Pattern: Ephemeral Test Stack 143 Antipattern: Dual Persistent and Ephemeral Stack Stages 145 Pattern: Periodic Stack Rebuild 146 Pattern: Continuous Stack Reset 147 Test Orchestration 149 viii | Table of Contents

Support Local Testing 149 Avoid Tight Coupling with Pipeline Tools 150 Test Orchestration Tools 150 Conclusion 151 Part III. Working with Servers and Other Application Runtime Platforms 10. Application Runtimes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Cloud Native and Application-Driven Infrastructure 156 Application Runtime Targets 157 Deployable Parts of an Application 157 Deployment Packages 158 Deploying Applications to Servers 159 Packaging Applications in Containers 159 Deploying Applications to Server Clusters 160 Deploying Applications to Application Clusters 161 Packages for Deploying Applications to Clusters 162 Deploying FaaS Serverless Applications 163 Application Data 164 Data Schemas and Structures 164 Cloud Native Application Storage Infrastructure 165 Application Connectivity 165 Service Discovery 166 Conclusion 168 11. Building Servers as Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 What’s on a Server 170 Where Things Come From 171 Server Configuration Code 172 Server Configuration Code Modules 173 Designing Server Configuration Code Modules 174 Versioning and Promoting Server Code 175 Server Roles 175 Testing Server Code 176 Progressively Testing Server Code 177 What to Test with Server Code 177 How to Test Server Code 178 Creating a New Server Instance 179 Hand-Building a New Server Instance 180 Using a Script to Create a Server 181 Using a Stack Management Tool to Create a Server 181 Table of Contents | ix

Configuring the Platform to Automatically Create Servers 182 Using a Networked Provisioning Tool to Build a Server 182 Prebuilding Servers 183 Hot-Cloning a Server 184 Using a Server Snapshot 184 Creating a Clean Server Image 185 Configuring a New Server Instance 185 Frying a Server Instance 186 Baking Server Images 187 Combining Baking and Frying 188 Applying Server Configuration When Creating a Server 189 Conclusion 189 12. Managing Changes to Servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Change Management Patterns: When to Apply Changes 192 Antipattern: Apply On Change 192 Pattern: Continuous Configuration Synchronization 194 Pattern: Immutable Server 195 How to Apply Server Configuration Code 198 Pattern: Push Server Configuration 198 Pattern: Pull Server Configuration 200 Other Server Life Cycle Events 202 Stopping and Restarting a Server Instance 202 Replacing a Server Instance 203 Recovering a Failed Server 204 Conclusion 205 13. Server Images as Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 Building a Server Image 208 Why Build a Server Image? 208 How to Build a Server Image 209 Tools for Building Server Images 209 Online Image Building Process 210 Offline Image Building Process 213 Origin Content for a Server Image 214 Building from a Stock Server Image 215 Building a Server Image from Scratch 215 Provenance of a Server Image and its Content 215 Changing a Server Image 216 Reheating or Baking a Fresh Image 216 Versioning a Server Image 217 Updating Server Instances When an Image Changes 218 x | Table of Contents

Providing and Using a Server Image Across Teams 220 Handling Major Changes to an Image 220 Using a Pipeline to Test and Deliver a Server Image 221 Build Stage for a Server Image 222 Test Stage for a Server Image 223 Delivery Stages for a Server Image 224 Using Multiple Server Images 225 Server Images for Different Infrastructure Platforms 225 Server Images for Different Operating Systems 225 Server Images for Different Hardware Architectures 226 Server Images for Different Roles 226 Layering Server Images 226 Sharing Code Across Server Images 228 Conclusion 228 14. Building Clusters as Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Application Cluster Solutions 230 Cluster as a Service 230 Packaged Cluster Distribution 231 Stack Topologies for Application Clusters 232 Monolithic Stack Using Cluster as a Service 233 Monolithic Stack for a Packaged Cluster Solution 234 Pipeline for a Monolithic Application Cluster Stack 235 Example of Multiple Stacks for a Cluster 238 Sharing Strategies for Application Clusters 241 One Big Cluster for Everything 242 Separate Clusters for Delivery Stages 242 Clusters for Governance 243 Clusters for Teams 244 Service Mesh 244 Infrastructure for FaaS Serverless 246 Conclusion 248 Part IV. Designing Infrastructure 15. Core Practice: Small, Simple Pieces. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Designing for Modularity 252 Characteristics of Well-Designed Components 252 Rules for Designing Components 253 Use Testing to Drive Design Decisions 256 Modularizing Infrastructure 256 Table of Contents | xi

Stack Components Versus Stacks as Components 257 Using a Server in a Stack 259 Drawing Boundaries Between Components 262 Align Boundaries with Natural Change Patterns 262 Align Boundaries with Component Life Cycles 263 Align Boundaries with Organizational Structures 265 Create Boundaries That Support Resilience 265 Create Boundaries That Support Scaling 266 Align Boundaries to Security and Governance Concerns 269 Conclusion 270 16. Building Stacks from Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271 Infrastructure Languages for Stack Components 272 Reuse Declarative Code with Modules 272 Dynamically Create Stack Elements with Libraries 273 Patterns for Stack Components 274 Pattern: Facade Module 274 Antipattern: Obfuscation Module 276 Antipattern: Unshared Module 277 Pattern: Bundle Module 278 Antipattern: Spaghetti Module 280 Pattern: Infrastructure Domain Entity 283 Building an Abstraction Layer 284 Conclusion 285 17. Using Stacks as Components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 Discovering Dependencies Across Stacks 287 Pattern: Resource Matching 288 Pattern: Stack Data Lookup 291 Pattern: Integration Registry Lookup 294 Dependency Injection 296 Conclusion 299 Part V. Delivering Infrastructure 18. Organizing Infrastructure Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 Organizing Projects and Repositories 303 One Repository, or Many? 304 One Repository for Everything 304 A Separate Repository for Each Project (Microrepo) 307 Multiple Repositories with Multiple Projects 308 xii | Table of Contents

Organizing Different Types of Code 309 Project Support Files 309 Cross-Project Tests 310 Dedicated Integration Test Projects 311 Organize Code by Domain Concept 312 Organizing Configuration Value Files 312 Managing Infrastructure and Application Code 313 Delivering Infrastructure and Applications 314 Testing Applications with Infrastructure 315 Testing Infrastructure Before Integrating 316 Using Infrastructure Code to Deploy Applications 317 Conclusion 319 19. Delivering Infrastructure Code. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Delivering Infrastructure Code 321 Building an Infrastructure Project 322 Packaging Infrastructure Code as an Artifact 323 Using a Repository to Deliver Infrastructure Code 323 Integrating Projects 326 Pattern: Build-Time Project Integration 327 Pattern: Delivery-Time Project Integration 330 Pattern: Apply-Time Project Integration 333 Using Scripts to Wrap Infrastructure Tools 335 Assembling Configuration Values 336 Simplifying Wrapper Scripts 337 Conclusion 338 20. Team Workflows. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 The People 340 Who Writes Infrastructure Code? 342 Applying Code to Infrastructure 344 Applying Code from Your Local Workstation 344 Applying Code from a Centralized Service 345 Personal Infrastructure Instances 347 Source Code Branches in Workflows 348 Preventing Configuration Drift 349 Minimize Automation Lag 349 Avoid Ad Hoc Apply 350 Apply Code Continuously 350 Immutable Infrastructure 351 Governance in a Pipeline-based Workflow 352 Reshuffling Responsibilities 352 Table of Contents | xiii

Shift Left 353 An Example Process for Infrastructure as Code with Governance 353 Conclusion 354 21. Safely Changing Infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Reduce the Scope of Change 355 Small Changes 358 Example of Refactoring 359 Pushing Incomplete Changes to Production 361 Parallel Instances 361 Backward Compatible Transformations 364 Feature Toggles 366 Changing Live Infrastructure 368 Infrastructure Surgery 370 Expand and Contract 372 Zero Downtime Changes 375 Continuity 376 Continuity by Preventing Errors 377 Continuity by Fast Recovery 378 Continuous Disaster Recovery 379 Chaos Engineering 379 Planning for Failure 380 Data Continuity in a Changing System 382 Lock 382 Segregate 382 Replicate 383 Reload 383 Mixing Data Continuity Approaches 384 Conclusion 384 Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 xiv | Table of Contents

1 For example, many government and financial organizations in countries without a cloud presence are pre‐ vented by law from hosting data or transactions abroad. 2 The research published by DORA in the State of DevOps Report finds that heavyweight change-management processes correlate to poor performance on change failure rates and other measures of software delivery effec‐ tiveness. 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 we’re 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. These days cloud technology is pervasive. Even the largest, most hidebound organiza‐ tions are rapidly adopting a “cloud-first” strategy. Those organizations that find themselves unable to consider public clouds are adopting dynamically provisioned infrastructure platforms in their data centers.1 The capabilities that these platforms offer are evolving and improving so quickly that it’s hard to ignore them without risking obsolescence. Cloud and automation technologies remove barriers to making changes to produc‐ tion systems, and this creates new challenges. While most organizations want to speed up their pace of change, they can’t afford to ignore risks and the need for gov‐ ernance. 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 technologies—slowing work down and harming stability.2 Preface | xv

In Chapter 1 I use the terms “Iron Age” and “Cloud Age” (“From the Iron Age to the Cloud Age” on page 2) 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 don’t 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 didn’t see a cohesive collection of guid‐ ance 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 didn’t 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 evolv‐ ing our ideas for managing Infrastructure as Code. What’s 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 infra‐ structure action has moved to managing collections of infrastructure resources provi‐ sioned from cloud platforms—what 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 I’ve 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. I’ve changed quite a bit based on what I’ve learned about the evolving challenges and needs of teams building infrastructure. As I’ve already touched on in this preface, I see making it safe and easy to change infrastructure as the key benefit of xvi | Preface

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, it’s that they are overwhelmed by the need to update, fix, and improve their systems. So I’ve 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 These are easier and safer to change than larger pieces. These three practices are mutually reinforcing. Code is easy to track, version, and deliver across the stages of a change management process. It’s easier to continuously test smaller pieces. Continuously testing each piece on its own forces you to keep a loosely coupled design. These practices and the details of how to apply them are familiar from the world of software development. I drew on Agile software engineering and delivery practices for the first edition of the book. For this edition, I’ve also drawn on rules and practi‐ ces for effective design. In the past few years, I’ve seen teams struggle with larger and more complicated infrastructure systems, and I’ve seen the benefits of applying lessons learned in soft‐ ware design patterns and principles, so I’ve included several chapters in this book on how to do this. I’ve also seen that organizing and working with infrastructure code is difficult for many teams, so I’ve addressed various pain points. I describe how to keep codebases well organized, how to provide development and test instances for infrastructure, and how to manage the collaboration of multiple people, including those responsible for governance. Preface | xvii

What’s Next I don’t believe we’ve matured as an industry in how we manage infrastructure. I’m hoping this book gives a decent view of what teams are finding effective these days. And a bit of aspiration of what we can do better. I fully expect that in another five years the toolchains and approaches will evolve. We could see more general-purpose languages used to build libraries, and we could be dynamically generating infrastructure rather than defining the static details of envi‐ ronments at a low level. We certainly need to get better at managing changes to live infrastructure. Most teams I know are scared when applying code to live infrastruc‐ ture. (One team referred to Terraform as “Terrorform,” but users of other tools all feel this way.) What This Book Is and Isn’t The thesis of this book is that exploring different ways of using tools to implement infrastructure can help us to improve the quality of services we provide. We aim to use speed and frequency of delivery to improve the reliability and quality of what we deliver. So the focus of this book is less on specific tools, and more on how to use them. Although I mention examples of tools for particular functions like configuring servers and provisioning stacks, you won’t find details of how to use a particular tool or cloud platform. You will find patterns, practices, and techniques that should be relevant to whatever tools and platforms you use. You won’t find code examples for real-world tools or clouds. Tools change too quickly in this field to keep code examples accurate, but 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. See the book’s companion website for references to example projects and code. This book won’t guide you on how to use the Linux operating system, Kubernetes cluster configuration, or network routing. The scope of this book does include ways to provision infrastructure resources to create these things, and how to use code to deliver them. I share different cluster topology patterns and approaches for defining and managing clusters as code. I describe patterns for provisioning, configuring, and changing server instances using code. You should supplement the practices in this book with resources on the specific oper‐ ating systems, clustering technologies, and cloud platforms. Again, this book explains approaches for using these tools and technologies that are relevant regardless of the particular tool. xviii | Preface