The last week I had a speaker at an italian service provider interested in IT automation of own infrastructure, about Ansible. The presentation is available at Speakerdeck (in Italian). To introduce the speak I did a bit of introduction about IT automation and his source mindset.
If you watch some job offers in the IT operations side market, you can see that the knowledge of at least one system for automation and configuration provisioning is become a strong requisite to apply. This situation is child of the virtualization and cloud revolution, that increased esponentially the number of IT equipment to be managed, and it goes hand in hand with devops movement born and growth. Before to come to analyze the various tools developed (like Ansible), we need to analyze the new mindset that cause the develop of system like Ansible. In the new mindset there are three main principles: automation, separation between infrastructure and infrastructure state and to manage infrastructure (state) as code.
Automation
This is not a new concept in IT system administration, scripting is a must for every sysadmin. This is a key point because it permits to save time, especially in complex infrastucture of thousand of machines and it permits to delete the human error during the execution of commands. During operations, especially apparently simple and repetitive operations, an human, for internal or external distraction, because in needed of a strong coffee, because of pressure, or what else, could underrate the current operation and could fail. You can have strong procedure but if you have simple and repetitive procedure (that it's good) an human will fail, repeatedly. We are not machines. If you have in place a some sort of automation system, you have to pay attention "only" to develop and to test the automation rules, then you will be "sure" of perfect repetition of the procedure, no distraction or human fail, at the worst only big machines fails.
Separation between infrastructure and infrastructure state
Usually the infrastructure and the infrastructure state are seen like an one entity. So with the infrastructure term we identify hardware (real or virtualized), operating system, system-role application (every sort of server) and their configurations. This is a heterogeneous set of things that seems to be too big. If you have to change a configuration, in the 90% of the time you are not interested in the OS base or in the hardware layer. This low level layers would be some sort of default and stock options to be considered as immutable. You know that you have an infrastructure base where to apply your desidere infrastructure state by your configurations. At the best, if you change your infrastructure base you don't have to change your infrastructure state and vice versa, they are logically separated.
Infrastucture (state) as code
The last step is to treat the infrastructure state and configuration as code. When you develop an application you work on a small set of workstations (your and your teammate), use a versioning system (isn't it?), you pass the application in testing and staging environment and then you deploy to production environment. If you need to modify something you modify locally, test it, put it on the versioning system and then put the new version in production. You don't need to go to evey single machine to change a single line of code, why would you need to go to every single machine to change one or more lines of a configuration file? And more, with a versioning system as repository of configuration you have full audit and visibility of the intended state of the infrastructure. It' a big deal.
An example
You have an application deployed on multiple Amazon EC2 instances and you have set autoscaling so new instances could be created and old could be destroyed based on your rules about time or current up instances state. When an instance is created there are two approches to have it ready for production. In an old fashion way you customize an Amazon Machine Image to your need and then, when the new instance starts, it loads this image. Bad. Automation, yes. But what about separation between infrastructure and infrastructure state? In the new fashioned way you start a stock AMI that will be always the same, and in the bootstrap of the instance you can use an automation system to pull from your versioning system your last tested and stable configuration and your last tested and stable application to deploy the new instance. So the configurations files and infrastructure state become a special case of the deploy of some generic code. Good. We have automation, separation and infrastructure state as code.