Terraform for backend engineers: what you actually need to know

Most backend engineers interact with infrastructure as a consumer: the platform team handles it, you deploy to it. At some point that changes — startup, freelance, or just a team that expects full-stack ownership. Terraform is the tool you want for that.

Why Terraform over click-ops

The obvious answer is reproducibility. A Terraform config is a description of desired state. You can destroy your staging environment and recreate it in minutes, identical. You can diff infrastructure changes like code.

The less obvious answer is review culture. When infrastructure changes live in PRs, they get reviewed. A config change that opens port 22 to the world gets caught before it reaches production.

State: the thing that actually matters

Terraform tracks what it’s created in a state file. This is where most beginner pain comes from.

Never store state locally in a team. Use S3 + DynamoDB locking from day one.

terraform {
  backend "s3" {
    bucket         = "myapp-terraform-state"
    key            = "production/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

Use workspaces for environment isolation. terraform workspace select staging gives you isolated state per environment.

Modules: the abstraction layer

Modules are Terraform’s equivalent of functions. Extract anything you’d reuse across environments.

modules/
  vpc/
    main.tf
    variables.tf
    outputs.tf
  ecs-service/
    main.tf
    variables.tf
    outputs.tf

Your environment configs become thin:

module "api_service" {
  source        = "../../modules/ecs-service"
  name          = "api"
  image         = var.api_image
  cpu           = 512
  memory        = 1024
  desired_count = 2
}

The plan/apply workflow

terraform plan is non-destructive and tells you exactly what will change. Treat it like a diff. Never apply without reading the plan.

For CI/CD: run plan on every PR, post the output as a comment, apply on merge to the target branch. This creates infrastructure review as a first-class concern.

What to learn next

State management → modules → remote backends → workspace patterns. In that order. Don’t reach for complex patterns (Terragrunt, component architecture) until you’ve hit the problem they solve.

The best infrastructure is the one your team can reason about and modify with confidence. Complexity has a carrying cost.