Infrastructure as Code — Concepts and Benefits

beginner iac idempotency declarative automation

Imagine we need to set up 10 servers, each with the same software, same firewall rules, same users. Doing it by clicking through a cloud console? That’s a recipe for missed steps and “it works on my server” problems. Infrastructure as Code (IaC) means we write code that defines our infrastructure, and tools execute that code to create the actual resources.

In simple language, instead of clicking “Create Instance” in the AWS console, we write a file that says “I want an instance with these specs” and a tool makes it happen.

Why IaC Matters

  • Reproducibility — run the same code, get the same infrastructure. Every time.
  • Version control — our infra lives in Git. We can review changes in PRs, roll back mistakes, and see who changed what.
  • Disaster recovery — server died? Run the code again. Done.
  • Consistency — no more “this staging server is slightly different from prod” situations.
  • Speed — spinning up a new environment goes from hours of clicking to minutes of automation.

Declarative vs Imperative

These are the two approaches to IaC, and the difference is like ordering food at a restaurant.

Declarative (WHAT)
"I want 3 nginx servers with 4GB RAM"
The tool figures out HOW to get there
Run it again? No changes (already in desired state)
Tools: Terraform, CloudFormation, Pulumi
Imperative (HOW)
"Create a server, then install nginx, then open port 80..."
We write every step ourselves
Run it again? Might break (duplicate resources)
Tools: Bash scripts, AWS CLI, SDKs

Most modern IaC tools are declarative. We describe the end state, and the tool calculates the steps needed to reach it.

Idempotency

This is a fancy word for a simple concept: running the same thing twice gives the same result. If we declare “I want 3 servers” and we already have 3 servers, a good IaC tool does nothing. It doesn’t create 3 more. That’s idempotency.

This is huge for safety. We can re-run our IaC code without fear of creating duplicate resources or breaking things.

  • Terraform — the most popular, works with every cloud provider. Declarative, uses HCL language.
  • Pulumi — like Terraform but we write real code (Python, TypeScript, Go) instead of a custom language.
  • AWS CloudFormation — AWS-only, uses YAML/JSON. Tightly integrated with AWS services.
  • Ansible — technically a configuration management tool, but can also provision infrastructure. Uses YAML playbooks.

Think of it like this: Terraform/CloudFormation create the servers, and Ansible configures what’s inside them. They’re often used together.

In simple language, IaC is treating our servers and cloud resources the same way we treat application code — written in files, stored in Git, reviewed in PRs, and reproducible on demand.