Infrastructure As Code (IAC), A noob level intro!

With the growth of the internet, the number of devices connected to networks has become endless. We rely on infrastructure to manage these devices, ensure uptime, and handle the transmitted data efficiently. In this context, infrastructure includes virtual machines (VM instances), Docker containers, and networking components such as servers, routers, switches, and load balancers.

What is Infrastructure As Code (IAC)

Infrastructure As Code is a practice of deploying and managing IT infrastructure through human-readable and machine-processable code, this reduces human interaction as there is limited human intervention involved. This means IT infrastructure such as servers, routers, VM instances etc are configured and defined using human-readable scripts or configuration files.

Benefits of Infrastructure As Code

The core principle of IAC is automating the complete deployment and managing IT infrastructure with automation and minimal human intervention it has various benefits compared to manual deployment, some of them being:

• Time: As the tasks are automated, the time taken to deploy say 10 servers with Terraform may be similar to writing configuration manually for a single server. The automation helps in performing these repetitive tasks with ease as the configuration files are reusable and there’s no requirement to rewrite for every single deployment.
• Cost: Using tools like Terraform there is a reduction in time but also cost, as the process is now less resource-intensive and can be done with ease with limited human resources.
• Reduced Risk: As the configuration files are written they can be tested in a test environment before running in production, in addition, there is minimal human intervention and infrastructure is usually pre-defined hence reducing human errors and misconfiguration.
• Version Control: Every time you write a configuration file for your upcoming deployment the IAC will allow you to keep track of your configuration files in a VCS (Version Control System) such as Git. When required by the user you can just revert back to the previous version or just update the version even if you are running a different version in the production environment.

Declarative VS Imperative IAC

Declarative and Imperative are two approaches in IAC that are used to define and manage infrastructure or processes. The two approaches differ in the way they are described and how the final output is achieved

Declarative

• Defines the end state of the system or infrastructure
• Instead of the user its the tool that determines the steps to achieve the final state
• Idempotent: In other words running the code multiple times gives you the same results
• Example tools: Terraform, Ansible (when using YAML in declarative mode)) and Kubernetes YAML files.

You can read about data serialization formats like YAML, XML, and JSON by clicking here!

Below is an example code of Terraform in declarative IAC written in Hashicorp Configuration Language

resource "aws_instance" "web" {
  count         = 2
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"
}

Here we stated our end requirement that is we need two instances of a machine, that is declarative in nature and we didn’t define the steps to achieve this.

Advantages of the Declarative approach

• Focus only on the end state and not on the steps to achieve it.
• consistency: the system ends in the same state every time ensuring predictability.
• Easier to maintain as changes can be made just by changing the state definition.
• Idempotency: No matter how many times you run the code the infrastructure remains the same.

Imperative

• We explicitly define the steps we need to achieve the end goal.
• Each step is performed in an order.
• Less Idempotent: That is re-running the code might not always result in the same output.
• Example tools: Ansible (in ad-hoc commands), Bash scripts and Python Scripts

Below is an example of installing and starting an Apache server using Ansible (ad-hoc commands)

ansible all -m apt -a "name=apache2 state=latest" --become
ansible all -m service -a "name=apache2 state=started" --become

Here we define each individual step, the “apt” command allows you to install the “Apache” server, whereas the “Service” keyword allows you to define the state of the server that is “started”, hence this is considered as imperative as you are defining steps to reach the end goal instead of only stating the end result.

Advantages of the Imperative approach

• Granular Control Better control of the sequence of execution
• Flexibility Ideal for complex workflows and custom workflows
• Easier for debugging specific steps if anything goes wrong.

Conclusion

At the end Infrastructure As Code enables automation and has revolutionized Infrastructure management, enabling automation consistency and scalability. The declarative approach allows us to focus only on end state of the infrastructure and also ensures idempotency and reducing manual errors. Meanwhile the Imperative approach gives more granular control over infrastructure deployement especially for complex workflows that require precision, also ensures better debugging for each phase.

With these approaches tools like Terraform, Ansible, Kubernetes have helped in pipelining IAC, reducing risks, human errors, saving time and reducing workloads on network and cloud engineers. Using this we are able to achieve faster,effecient and consistent deployments in production environments and improved operational effeciency.