Infrastructre as Code (IaC)
How it came to be?
Traditionally setting up infrastructure for the code to run (think: servers, network configurations, etc) has been a manual task.
People started using SOP (Standard Operating Procedure) in order to mitigate errors and risk (by listing down all the actionable items) but it’s still error-prone.
Enter, Infrastructure as code.
This is an attempt to abstract the tangible aspects of software (hardware it runs on, configurations and network it uses, etc). Instead of executing a bunch of documented steps we now have some way of doing that programmatically.
Situation:
You have to run a web application (on tomcat for eg) which needs a running instance of mysql, needs 2 GB RAM, requires a bunch of tools and utilities to be installed for it to run properly (java-8, ssh, etc).
Scenario 1:
A dedicated guy spawns a new VM instance. He installs all the items in the list one by one.
Scenario 2:
You have a Dockerfile which contains all the dependencies and the requirement in it. You just create an image (or pull it out of docker hub or some other custom docker repository)
The second approach here is treating the server required as ‘code’ rather than as some physical entity.
- This avoids a lot of scenarios where something could be missed or wrongly configured.
- This is highly efficient. Imagine having to do that for 100 instances, 200 instances or even more.
- You have a single reliable source of truth when you want to debug. It clearly chronicles all the changes, configurations applied (network settings, dns configurations, etc). I used docker as an example. There are other ‘ways’ of doing IaC too. Ansible, SaltStack come to mind.