Terraform

What It Is

Terraform is an open source Infrastructure as Code tool built by HashiCorp. It lets you define cloud infrastructure, virtual machines, databases, DNS records, IAM policies, Kubernetes clusters, and hundreds of other resources, in declarative configuration files written in HashiCorp Configuration Language (HCL). You describe what infrastructure you want, and Terraform works out what needs to be created, changed, or destroyed to make that happen. It supports every major cloud provider through a plugin system called providers, with the AWS, Azure, and GCP providers each having thousands of resources available.

Why It Matters

Infrastructure managed through a cloud console or a collection of ad hoc scripts has a fundamental problem: nobody knows the true current state of the system. A resource created manually three years ago, by someone who has since left the team, with settings nobody has reviewed since, is a liability. Terraform makes infrastructure legible. Because every resource is defined in code, checked into version control, and applied through a repeatable process, the configuration files become the single source of truth for what exists.

The plan then apply workflow is one of Terraform’s most underappreciated features. Running terraform plan before any change produces a detailed diff showing exactly what will be created, modified, or destroyed. Teams can review infrastructure changes in a pull request the same way they review code changes. A destructive modification that would cause outage becomes visible before it happens, not during.

Terraform also changed the conversation around environment parity. Spinning up an identical copy of a production environment for testing or disaster recovery, something that previously took weeks of manual work, becomes a matter of running the same configuration with a different variable file. Environments stop being snowflakes and start being reproducible artifacts.

In Practice

• Remote state: Terraform tracks what it has deployed in a state file. For team use, this file must live in a shared backend like S3 with DynamoDB locking or Terraform Cloud, so that concurrent runs do not corrupt each other’s view of the world.
• Modules: reusable configuration blocks. A module might encapsulate a standard VPC layout, a hardened EKS cluster, or a compliant RDS instance. Teams publish internal modules to a private registry, ensuring that everyone follows the same approved patterns rather than inventing their own.
• Workspaces and variable files: a single set of configuration files can manage multiple environments through workspaces or separate variable files (dev.tfvars, prod.tfvars). Resource counts, instance sizes, and feature flags all become variables, keeping environment differences explicit and auditable.
• Import: existing infrastructure created outside Terraform can be imported into the state file, allowing teams to gradually bring manually managed resources under Terraform control without destroying and recreating them.
• CI/CD integration: terraform plan runs on every pull request and posts the diff as a comment. terraform apply runs on merge to the main branch. The Atlantis project and Terraform Cloud both automate this workflow with locking and approval gates.

Key Insight

Terraform is most valuable as a forcing function for conversations that teams would otherwise avoid. Defining a resource in HCL requires answering questions: which subnet does this go in? What are the CIDR ranges? Who should have access? A resource created by clicking through a console skips all of those questions and buries the answers in a configuration that is invisible to everyone who was not in the room. Terraform makes the answers compulsory and permanent.