Key takeaways
|
In this article we review the book Infrastructure as Code - Managing Servers in the Cloud written by Kief Morris, who is leading Continuous Delivery and DevOps at ThoughtWorks Europe. In over 300 pages, Morris lays down the foundation for Infrastructure as Code and outlines the main patterns and practices recommended for building it.
We started by asking the author a few questions related to his book.
InfoQ: Please, tell us a bit about your role today.
Kief Morris: As the head of ThoughtWorks’ Cloud Practice in the UK, I’m involved in helping clients use cloud, infrastructure, and platforms for delivering and running software. Things are shifting rapidly in the industry; a year or so ago, cloud was exclusively a tool for innovators to escape the constraints of traditional IT. Now, traditional IT groups are exploring how they can use cloud.
InfoQ: Why does cloud and automation make things harder for the infrastructure team?
Morris: The wonderful thing about cloud is that it makes it easy for anyone in the organization to provision, configure, and manage the infrastructure they need. The terrifying thing about cloud is - well, the same thing. How can the infrastructure team give its users the keys to the cloud without unleashing a maelstrom of poorly configured, insecure and unstable systems?
InfoQ: Why would one adopt Infrastructure as Code?
Morris: Infrastructure as Code brings principles, practices and tools from software engineering to bear on managing dynamic infrastructure. Infrastructure is defined in files, managed in source control, applied consistently across environments, and tested and promoted through pipelines. Infrastructure code is organized in ways that keep it loosely coupled, reduce technical debt and to allow multiple teams to work on it effectively.
This approach means changes can be delivered quickly and more frequently than with manual processes, with more reliability and more control. Application teams can edit and push the files that configure their environments on their own. If the infrastructure team can invest effort in making sure the pipelines and automated testing is robust enough to catch problems before they hit important systems, they don’t need to spend time manually carrying out every change that the application team needs. This is a virtuous cycle for everyone involved.
InfoQ: What are some of the pitfalls that organizations risk falling into when adopting infrastructure-as-code technologies?
Morris: Many infrastructure teams adopt cloud and automation technologies but don’t implement them with this kind of automated testing and releasing process. They use them like an overly-complicated scripting language. They edit cookbooks, manifests, or playbooks, for a specific change, and then run them manually against a particular set of their servers, meaning every change still requires specialist knowledge, time and effort. Working this way means infrastructure teams aren’t freeing themselves from routine drudgery, and they aren’t reducing the risk of breaking things when they make a change, and they aren’t empowering their users.
The book is divided in three parts: Foundations, Patterns and Practices. In the first part, the author describes Infrastructure as Code, dynamic infrastructure platforms, some of the infrastructure definition and server configuration tools along with his recommendations on how infrastructure services should work in a dynamic setting. Some of the challenges encountered when dealing with a dynamic infrastructure are: server sprawl, configuration drift, snowflake servers, fragile infrastructure, automation fear and erosion.
The principles underlying a dynamic infrastructure mentioned by Morris are:
- Systems can be easily reproduced
- Systems are disposable
- Systems are consistent
- Processes are repeatable
- Design is always changing
Along with these principles, the author details a number of practices recommended when building infrastructure as code:
- Use definition files
- Create self-documented systems and processes
- Version everything
- Implement continuous testing
- Perform small changes
- Maintain services up continuously
The second part of the book includes patterns for provisioning servers, managing server templates, updating servers and defining the infrastructure. Regarding server provisioning, the author mentions a couple of antipatterns -server installed by hand and server cloned from a running server-, suggesting instead using a script to set up a server and starting servers from templates rather than cloning an existing one.
In the last part of the book, the author provides practical advice on setting up and maintaining a qualitative infrastructure based on practices learned from software development. Morris explains how to test infrastructure changes, especially performing automated testing meant to validate modifications within an infrastructure. It is important to discover misconfigurations early and avoid building a fragile system over time. The author recommends taking an Agile approach to testing, integrating it into the automated process used to manage the infrastructure, and executing tests after every change. He divides tests into layers: low-level tests - such as validating definition files-, medium-level tests – such as validating server roles-, and high-level tests – such as testing multitier services-.
Morris also explains how to introduce continuous delivery into an automated infrastructure by building a change management pipeline. The point of such a practice is to “create a process that is optimized to quickly and rigorously validate a continuous flow of small changes.”
One chapter is dedicated to guidance on building a workflow for an operations team working in a fully automated setting. The main characteristics of such a workflow are speed and reliability: “It must be possible to get a change through to systems fast enough that it’s a valid way to handle emergencies” and “the person making a change must be confident that it will work as expected and know whether it will create any new problems.”
Chapter 14 discusses “continuity”, a term used to express operational quality needed in a production environment. The operations team needs to make sure that services are running properly, responding timely and providing the appropriate data. Security should be enforce throughout the entire process. While the traditional approach to operational continuity is to limit change as much as possible, infrastructure as code takes the opposite approach requiring maximum flexibility in adapting the infrastructure as needed. In this chapter, the author explains how it can be done.
In the last chapter of the book, the author outlines several organizational principles meant to facilitate infrastructure as code within an organization:
- A continuous approach to the design, implementation, and improvement of services
- Empowering teams to continuously deliver and improve their services
- Ensuring high levels of quality and compliance while delivering rapidly and continuously
To provide a better feeling of the book’s content and style, we include an excerpt on “Working with Infrastructure Definition Tools” taken from Chapter 3, Infrastructure Definition Tools (O'Reilly Publishing). The topics covered are: Provisioning Infrastructure with Procedural Scripts, Defining Infrastructure Declaratively, Configuring Servers, and Configuration Registries.
About the Book Author
Kief Morris is cloud practice lead at ThoughtWorks. He enjoys helping ambitious organizations to harness disruptive ideas in software delivery and operations. This includes cloud platforms, infrastructure automation, DevOps, and Continuous Delivery. Originally from Tennessee, Kief has been been building teams to deliver software as a service in London since the dotcom days. He is the author of ‘Infrastructure as Code’ (O'Reilly Publishing).
