What is Infrastructure as Code and Why It's Transforming DevOps

What IaC is and the problem it solves
The idea behind infrastructure as Code (IaC) is that you write and execute code to define, deploy, update and destroy your infrastructure. This represents an important shift in mindset in which you treat all aspects of operations as software, even those aspects that represent hardware e.g setting up physical servers. A key insight is that you can manage almost everything in code like; servers, databases, network, application configuration, documentation, automated tests, deployment processes etc.

Now a good question to ask is why bother?

• Self-service

Most teams that deploy code manually have a small number of system admins who are the only ones who know all the magic incantations to make the deployment work and are the only ones with access to production. This becomes a major bottleneck as the company grows. If your infrastructure is defined in code, the entire deployment process can be automated and developers can kick off their own deployments whenever necessary.

• Speed and safety

If the deployment process is automated, it will be significantly faster since a computer can carry out the deployment steps far faster than a person. Also it's safer given that an automated process will be more consistent, more repeatable and not prone to manual error.

• Documentation

If your infrastructure is defined as code, then the state of your
infrastructure is in source files that anyone can read. In other words, IaC acts as documentation, allowing everyone in the organization to understand how things work, even if the system admin isn't available which happens sometimes.

• Version control

IaC source files can be stored in version control. This becomes a powerful tool for debugging issues because any time a problem pops
up, your first step will be to check the commit log and find out what changed in your infrastructure and can resolve problem by reverting back.

• Reuse

You can package your infrastructure into reusable modules so that instead of doing every deployment for every product in every environment from scratch, you can build on top of known, documented, battle-tested pieces.

The difference between declarative and imperative approaches
Imperative approach
This is a style you write code that specifies, step by step, how to achieve some desired end state.

- ec2:
    count: 10
    image: ami-0fb653ca2d3203ac1
    instance_type: t2.micro

Declarative approach
In this style you write code that specifies your desired end state,
and the IaC tool itself is responsible for figuring out how to achieve that state.

resource "aws_instance" "example" {
  count = 10
  ami = "ami-0fb653ca2d3203ac1"
  instance_type = "t2.micro"
}

Note: The code snippets represent this;
I want to deploy 10 EC2 instances to run AMI with ID ami-0fb653ca2d3203ac1 (Ubuntu 22.04).

Why Terraform is worth learning
Terraform is worth learning because it removes a lot of pain you don’t realize is avoidable unless you hear of it's capability or even get to use it. Instead of guessing or repeating manual steps, you just write down what your infrastructure should look like, and it handles the rest. The big win is consistency, you can spin up the same setup today, next week or on someone else’s machine and get the same result.

Your personal goals for this 30-day challenge

• Get comfortable enough to use Terraform without overthinking it.

• Be able to spin up and tear down real infrastructure confidently.

• Understand what’s happening under the hood (not just copy-paste configs).

• We all talk about scalability, this is my part of the journey in understanding that.

At the end of it, I just want to reach a point where if I need infra, I don’t hesitate....I just write it.