SaltyVagrantChapter 7
Infrastructure as Code
Central to our approach is the idea of infrastructure as code. What does this mean?
Hopefully we are all familiar with the fact that underlying the websites, applications, databases and other software in our charge is code. This code is transformed by other software (typically a compiler or interpreter) into a form that is ultimately executed under the management of an operating system (another piece of software). This code is, at least in well run modern environments, held in a version control system.
It seems peculiar then that all of the surrounding configuration, setup, and monitoring necessary for maintaining a system should be recorded in documents that are followed and maintained (hopefully consistently and accurately) by engineers. These documents are often called ‘run books’ and there are even tools that attempt to partially automate these run books1. This never works!
This problem is solved by replacing the documentation and manual execution with code that is executed by software designed to manage infrastructure. This may seem odd, sending software to look after software, but bear with me.
Using code to manage our system also provides other significant advantages; it is repeatable, and it can be put into version control. This may seem like a slight thing after all the manual documentation can be put under version control too. The difference is the repeatability. With the best will in the world humans suck at writing and following documentation. This is a combination of the document being unclear or incomplete and the engineer following the document interpreting it incorrectly or, with the best of intentions, ‘correcting’ the document as it is being implemented (often without updating the document).
We have removed the human element between writing the system specification and its implementation. Any problems with the interpretation of the infrastructure code can be corrected and the code re-run until the problems are resolved. In other words our infrastructure becomes subject to a cycle of debugging, just like software. Our objective, if it is not already obvious, is to produce instructions that can be executed without human intervention in a repeatable manner such that we can create or recreate our infrastructure.
Another often overlooked advantage of this infrastructure as code is speed. Anyone who has been involved in the manual deployment of a system will know it is not only error-prone (consequently one is never sure one has the system as specified) but it is also slow, painfully slow, and labour intensive. Infrastructure as code is front loaded, meaning most effort is invested at the beginning of the project. Once at the point of deployment it (ideally) is a push-button deployment. It can still take hours to deploy a system from scratch, but compared to the days or weeks involved in a manual deployment this is not a long time.