Why infrastructure as code

The problem with clicking

In the early modules you created resources by clicking in the AWS, Azure or Google Cloud console. That is fine for learning. In a real company it causes trouble. Nobody remembers exactly which 40 boxes were ticked. The test environment slowly becomes different from production. When someone leaves, their knowledge leaves too. And if a region has a bad day, rebuilding everything by hand can take days.

Infrastructure as code (IaC) solves this. You write a text file that describes the infrastructure: "one S3 bucket with versioning on, one VPC with two subnets, one database of this size". A tool reads the file and calls the cloud APIs (the web interfaces that the console itself uses) to make reality match the file.

What IaC gives you

• Repeatable: run the same files and get the same infrastructure, today or in two years.
• Reviewable in Git: every change is a commit with an author, a reason and a pull request that a teammate checks before it goes live.
• Fewer click mistakes: no forgotten checkbox, no typo in a security group rule made at 2 am.
• Disaster recovery: if a region or account is lost, you can rebuild the whole setup from the files (your data still needs separate backups).
• Matching environments: dev, test and production come from the same files with different settings, so "it worked in test" means something.
• Living documentation: the files show exactly what exists, which is more reliable than an old diagram.

Declarative versus imperative

An imperative approach lists the steps: "create a bucket, then turn on versioning, then add a tag". A declarative approach describes the end state: "there should be a bucket with versioning on and this tag". The declarative tool compares that wish with what already exists and does only what is missing.

# Imperative: a script of steps. Running it twice fails or makes duplicates.
aws s3api create-bucket --bucket results-dev-demo --region ap-south-1 \
  --create-bucket-configuration LocationConstraint=ap-south-1
aws s3api put-bucket-versioning --bucket results-dev-demo \
  --versioning-configuration Status=Enabled

# Declarative: the end state. Running it twice changes nothing the second time.
Resources:
  ResultsBucket:
    Type: AWS::S3::Bucket
    Properties:
      VersioningConfiguration:
        Status: Enabled

Idempotency

Idempotent means "doing it again gives the same result". Pressing a lift button five times still calls one lift. A good IaC apply is idempotent: the first run creates the bucket, the second run sees the bucket is already correct and does nothing. This is why you can safely run the same pipeline on every commit.

To be idempotent, the tool computes a plan: it compares the desired state (your files) with the current state (what exists) and lists the actions. A resource that is wanted but missing is created. A resource that exists but differs is updated. A resource that exists but is no longer in the files is deleted. A resource that already matches is left alone.

Drift

Drift is the difference between what your files say and what really exists, usually caused by someone changing a setting by hand in the console. If a developer opens port 22 to the whole internet "just for a minute" and forgets, the real security group has drifted from the code. CloudFormation has drift detection, and Terraform shows drift when it plans. The fix is to change the code (or undo the manual change) so the two match again.

Mutable versus immutable infrastructure

Mutable infrastructure is changed in place: you log in to a running server and upgrade packages. Over months each server becomes slightly different (people call these "snowflake" servers). Immutable infrastructure is never changed in place: you build a new machine image or container image with the change, start new servers from it, and throw the old ones away. Immutable setups are easier to reason about and roll back, and they fit well with IaC and auto scaling.

The tool landscape

Licences matter for some companies. In August 2023 HashiCorp moved Terraform from an open-source licence to the Business Source License (BSL 1.1). It is still free for most teams to use, but it limits building competing products. OpenTofu was forked from the last open-source version and is run under the Linux Foundation. On Google Cloud, most teams use Terraform or OpenTofu; check the current Google Cloud documentation for its managed IaC options.