At an open spaces session on configuration automation at a DevOpsDays a year or two ago, I asked the group how many of them were using an automation tools like Puppet or Chef. The majority of hands went up. I asked how many were running these tools unattended, on an automatic schedule. Quite a few of the hands went down.

Many people have the same problem I had in my early days of using automation tools. I used automation selectively, for example to help build new servers, or to make a specific configuration change. I tweaked the configuration each time I ran it, to suit the particular task I was doing.

I was afraid to turn my back on my automation tools, because I lacked confidence in what they would do.

I lacked confidence in my automation because my servers were not consistent.

My servers were not consistent because I wasn’t running automation frequently and consistently.

This is the automation fear spiral. Infrastructure teams need to break this spiral to use automation successfully.

The most effective way to break the spiral is to face your fears. Pick a subset of your servers, choose one or two things on them to put under configuration management, and then schedule these to be applied unattended, at least once an hour.

Starting small and simple helps to limit the risk. The important thing is that you take the leap - let the automation go on its own, without you holding its hand. Then you can increase the scope - add a few more parts of the server to the automation, and extend it to more servers.

You should also build out other things that will give you more confidence, piece by piece. Add monitoring to detect when the thing you’ve automated goes wrong. Set up Continuous Integration to automatically test the configuration change every time you commit. Again, getting these pieces in place with a small, simple set of configuration, creates the platform. You can then extend the coverage with confidence.

Systems administrators have probably been writing scripts and tools to make their jobs easier since day one. When I joined my first systems team, the mantra “let the machines do the boring work” was drilled into my head. The popularization of cloud (IaaS) and virtualized infrastructure over the past decade has given us the opportunity to automate the boring work in some very different, and cool ways.

We have moved from the Iron Age of infrastructure and into the Cloud Era. The resources of an IT infrastructure - compute, storage, and networking - have been transmogrified from inflexible physical hardware into dynamic software and data. In the Iron Age, the interface for creating a new server was a purchasing request form. In the Cloud Era, it’s a programmable API.

So. If our infrastructure is now software and data, manageable through an API, then this means we can bring tools and ways of working from software engineering and use them to manage our infrastructure. This is the essence of Infrastructure as Code.

In software engineering we write code, keep it in a Version Control System (VCS) and automatically test it with Continuous Integration (CI). We and deploy it to a series of environments using a Deployment Pipeline so it can be validated before putting it into production use. Now we can easily do the same with infrastructure.

Infrastructure as Code doesn’t only apply to cloud and virtualized infrastructures, it can also be used with “bare metal” infrastructure. I’ve worked with teams who’ve implemented dynamic hardware system management. We used Cobbler to automatically install servers using PXE-boot installation over a network. When we implemented this we had to start the installation at the physical server (boot the server and hold down F12, in our case). But many hardware vendors have Lights Out Management functionality that makes it possible to do this remotely, and even automatically.

I’ve run across many teams who are in the same place I was a few years ago, people who are using cloud, virtualization, and automation tools, but haven’t got it all running as smoothly as they know they could.

Much of the challenge is time. Day to day life for systems administrators is coping with a never-ending flow of critical work. Fighting fires, fixing problems, and setting up new business critical projects doesn’t leave much time to work on the fundamental improvements that will make the routine work easier.

My hope is that this book provides a practical vision for how to manage IT infrastructure, with techniques and patterns that teams can try and use. I will avoid the details of configuring and using specific tools, so that the content will be useful for working with different tools, including ones that may not exist yet. On the other hand, I will use examples from current tools to illustrate the point I make.

The Infrastructure as Code approach is essential for managing cloud infrastructure of any real scale or complexity, but they’re not exclusive to organizations using public cloud providers. The techniques and practices in this book have proven effective in virtualized environments, and even without any virtualization.