Introduction to Infrastructure as Code (IaC)

Back in the day, the traditional software systems ran on top of on-premise infrastructure, which was managed by a separate team of engineers with their own hardware.

When a requirement was received, the architects plan the required resources and hand over the requirements to the infrastructure teams. This team will allocate the required hardware resources for this and sometimes purchases the required hardware, allowing the developers to deploy their code once the infrastructure platform is ready.

Within this entire process, the turnover time was significant, causing the deployments to slow down drastically. Some challenges in the approach were:

• Slow deployment (certain deployments had specific hardware requirements which had to be provisioned by the infrastructure team. This provisioning and maintenance of infrastructure takes time, causing the deployment velocity to drop down)
• Expensive (Maintaining your own hardware came in with inherent costs of upgrading them, networking them, and even controlling your own server rooms. All these were simply to cater to a single organizational requirement)
• Limited automation (Except for a few processes, most works around this provisioning had to be done manually. As the system grows, you would require more and more operations engineers to maintain the hardware resources in your on-premise environment)
• Human error (Due to the higher number of manual processes, certain pipelines in this process were prone to human errors)
• Wasted resources (When the architects decide on the required hardware resources, they would make assumptions based on the maximum load capacity expected. With this, they had to allocate additional resources just to cope with the unexpected traffic from users)
• Inconsistencies (Since most servers are deployed separately, each of them needs software maintenance, system upgrades, and OS-level patching. This would have to be done manually to each of the servers, where there could occur certain inconsistencies when trying these on each server separately)

Cloud Service Providers

With time, when cloud infrastructure and services came into play, people started moving all their services to the cloud. Cloud computing came to relieve some of the pains you’ve just read about. It frees you from having to build and maintain your data centers and the high cost associated with it. They really didn't have to worry about infrastructure, because the infrastructure itself was provided as a service to the users. This came with a lesser cost due to their hardware virtualizations and even came with a fancy user interface (aka cloud console) to provide the resources.

This eliminated most of the problems mentioned above related to on-premise infrastructure, moving the burden of infrastructure maintenance completely to the cloud service provider. With elastic and highly scalable environments, the worry was around adding the required configurations and deploying the right software to the cloud.

As software systems grew, still the level of manual work to request and provision these resources in the cloud was high. Human errors and inconsistencies were high as well since the provisioning had to be done manually.

Infrastructure as Code

https://www.spec-india.com/blog/infrastructure-as-code-a-devops-way-to-manage-it-infrastructure

As a solution to this, engineers started using the APIs and SDKs provided by the cloud providers, to access and provision resources in the cloud in a programmatic manner. They started writing their own scripts to provision their hardware and update them. Many used shell scripts, python, and other scripting languages for this purpose. This gave birth to the process of writing Infrastructure as Code (IaC).

Infrastructure as Code (IaC) is the managing and provisioning of infrastructure through code instead of through manual processes.

When this became a common problem in the industry, several communities started building generalized tools for infrastructure provisioning, which became widely used by engineers all around the world and became a wide community around writing infrastructure as code in a human readable, simple, and high-level language.

Version Controlling of your Infrastructure

A major advantage of IaC is to provide support for version controlling your infrastructure resources. Technically, this happens to your code which describes the infrastructure. Indirectly it also applies version controlling to the infrastructure provisioned by that code.

Deploying your infrastructure as code also means that you can divide your infrastructure into modular components that can then be combined in different ways through automation.

IaC Tools

Some of the common tools available out there are:

• Ansible
• Terraform
• Puppet
• Cloudformation
• Packer
• Saltstack
• Vagrant
• Docker
• And many more…

These are all addressing the same problem. But IAC can be broadly classified into three types

• Configuration management (eg: Saltstack, Ansible, Puppet)
• Server templating (eg: Docker, Packer, Vagrant)
• Provisioning tools (eg: Terraform, Cloud formation)

Configuration Management

This was mainly around the required configurations around hardware resources. To install and manage software on existing infrastructure resources. (servers, DBs, networking devices, etc).

These tools introduce an easy way of writing required configuration as code, so that consistency can be maintained in terms of used configurations in the infrastructure resources.

This also gives the ability to control versions of configurations and software updates/upgrades allowing quick roll forward and backward of software versions when required with a few lines of code. In an organization with over 100 servers, if this had to be done manually, the engineers would have to go through each server to update the relevant software.

Another advantage of codifying this process was being idempotent. This means, that no matter how many times we execute these tools, they will only try to bring the infrastructure into the desired state and not repeat the changes over and over again.

Server templating tools

These tools are mainly responsible for maintaining custom images, virtual machines, containers, and templates required by infrastructure resources.

These images and virtual machines come with pre-installed software and dependencies which can be readily used based on the company standards and processes. These are specifically tailored for the company’s software requirements and allow engineers to worry about deploying software than installing the underlying dependencies of their servers.

This makes the infrastructure immutable as well. Once the VM or container is deployed, it will remain as it is, where changes will not be done manually to them. If changes are needed, then we need to make those changes via our server templating tools to update the image and redeploy.

Provisioning tools

This is about provisioning infrastructure resources with a simple declarative code. Based on our required cloud service provider, we simply have to declare which resources we need and these tools will simply provide them for us via the relevant cloud provider's APIs/SDKs.

Terraform is the infamous infrastructure provisioning tool available in the market today which is vendor-agnostic and provides provider plugins for over 100s of vendors out there.

On the other hand, Cloud Formation is also another well-used tool that is specifically built for AWS.

References

1. https://www.redhat.com/en/topics/automation/what-is-infrastructure-as-code-iac
2. https://kodekloud.com/courses/lab-terraform-for-beginners/?utm_source=youtube&utm_medium=labs&utm_campaign=terraform
3. https://stackify.com/what-is-infrastructure-as-code-how-it-works-best-practices-tutorials/