Infrastructure as code

Infrastructure as code, or programmable infrastructure, means writing code (which can be done using a high level language or any descriptive language) to manage configurations and automate provisioning of infrastructure in addition to deployments. This is not simply writing scripts, but involves using tested and proven software development practices that are already being used in application development. For example: version control, testing, small deployments, use of design patterns etc. In short, this means you write code to provision and manage your server, in addition to automating processes.

Infrastracture as Code by Kief Morris 

It differs from infrastructure automation, which just involves replicating steps multiple times and reproducing them on several servers.

With this, the knowledge of server provisioning, configuration management and deployment is no longer only with the systems admins. Even developers can easily engage in the activities, because they can easily write infrastructure code in the languages that they are familiar with. In addition to this, the learning curve for most descriptive languages used by tools like ansible is not very steep. This makes devops even simpler for a developer.

A vast number of tools like vagrant, ansible, puppet, docker makes the whole process even easier. This is even made better by the fact that server hosting sites like aws are providing RESTful apis that can be leveraged.

All these actions are carried out automatically when the playbook is run. And irrespective of the number number of times it is run, if the task required has already been executed on the machine, the task will not be run again. In other words, it just ensures the machine is in the required state.

Also worth noting is - you can run it from your machine (or any other that has ansible installed) and it is applied to all the machines as specified in your inventory file.

Virtualisation tools like virtualbox and vagrant or docker are really helpful during development as well.

Virtualbox allows you to run several multiple machines with different operating systems on your own computer.

Vagrant wraps around any virtualization tool, to help you quickly spin up the boxes. It bases on already built images (or call them boxes). So you just add it, specify it in your vagrant file, spin up the box and you are good to go. It also allows you to specify the provisioning method or tool to use (e.g chef or ansible) and the script to use. Then it can automatically carry out the provisioning for you.

Docker leverages chroot and linux containers (lxc) to allow you to spin up (and provision if you want) multiple lightweight containers on your machine. This can even be helpful if you are developing for a micro-service architecture.

With the help of these tools and more, development and testing becomes simpler, as one can easily spin up a server and fully configure it even on their development box for use while developing. This eliminates breaking of the common server that is usually shared during development. The QAs can also do the same thing. For example: easily spin up another for his staging environment.

Despite all the different machines involved, there is a sense of confidence that all of them have the same configurations, thus avoiding issues like snowflake servers.

The ability to use version control on your infrastructure code implies that you can easily track all the changes in your infrastructure environment. Therefore, you have an easier option of rolling back configuration changes to a previous working configuration in case of a problem.

The other sweeter part is that your configurations have the possibility to run on almost anything, from local machine to local physical servers, cloud and virtualisation tools.

On the other hand, there are a few glitches:

1. Having to plan much before the configuration - such as choosing the right tools

2. Bad configurations could get duplicated on all the servers

3. Configuration drift, in which the server configurations are modified on the machines (for example, through hot-fixes without modifying the original templates), makes configurations on the server and in the template to differ. This is   especially true if strict discipline is not followed.