Terraform

Terraform has transformed infrastructure management since 2014: instead of clicking through a cloud console to create servers, you write code describing the desired state, and the tool applies it. This is called 'Infrastructure as Code'. For an SMB or a technical team, the stake is concrete: your infrastructure becomes reproducible, versioned like application code, and if a server disappears, you can recreate it in 10 minutes instead of several days.

• →OpenTofuOpen-source fork of Terraform after the HashiCorp license change: 99% compatibleView page
• →PulumiIf you prefer describing infra in a real programming language (TypeScript, Python, Go)
• →AWS CDKIf you're 100% AWS and want to leverage the native TypeScript-first approach
• →AnsibleFor configuration management rather than provisioning, often complementary to Terraform

1. 01

   Start minimal: one environment, simple modules, no over-engineering

2. 02

   Remote and locked state (S3 + DynamoDB, or Terraform Cloud): never local state

3. 03

   Reusable modules only when the pattern is confirmed across 2-3 uses

4. 04

   Infrastructure tests (terraform plan in CI, optionally Terratest)

5. 05

   Documentation alongside code: why this resource exists, not only how

• At how many servers does Terraform become useful?

  Starting at 5 cloud resources to manage (servers, databases, buckets, networks), or as soon as you have multiple environments to keep consistent. For 1-2 simple servers, it's usually over-engineering: a Dockerfile and docker-compose are enough. The breakeven point is often when you start wondering who modified what on the cloud.
• Terraform or OpenTofu?

  OpenTofu is the open-source fork created after the HashiCorp license change in 2023, now maintained by the Linux Foundation. Technically 99% compatible with Terraform, and more aligned philosophically with pure open source. For new projects, OpenTofu is a defensible choice. For existing projects, migration isn't urgent.
• What does it cost to set up Terraform on existing infrastructure?

  For an SMB with 5-10 cloud resources, expect 5 to 15 days of initial setup: inventory of existing resources, import into Terraform without breaking active resources, structuring into reusable modules, CI setup. Investment quickly amortized through reduced incidents and faster provisioning.
• How do I avoid the badly-written Terraform trap?

  Three key rules: start minimal (one environment, simple modules), remote and locked state mandatory (never local state in a team), refactor into modules only when the pattern is confirmed across 2-3 real uses. The classic trap is over-abstracting too early before having domain experience.
• Do I need to know AWS or GCP before Terraform?

  Yes, that's actually essential. Terraform is an infrastructure description tool, but it doesn't replace understanding the underlying cloud. You need to know what a VPC, an IAM role, a load balancer is. Terraform helps you deploy them reproducibly, but doesn't teach you how to design them.