Terraform

What Terraform Does#

Terraform reads HCL files declaring resources, queries the relevant provider APIs to learn the current state, computes the diff, and applies changes in dependency order. The state is stored in a file (locally or in a remote backend like S3, Azure Blob, GCS, or HCP Terraform); the diff is the difference between the declared HCL and that state.

The model is intentionally simple: HCL is data, not a program. There are loops (`for_each`, `count`), conditionals (`for` expressions, dynamic blocks), and functions, but the language is deliberately constrained. Complex logic lives in modules — reusable bundles of HCL — or moves out to wrappers (Terragrunt, Atlantis, Spacelift).

The BUSL Relicensing and OpenTofu#

In August 2023 HashiCorp relicensed Terraform from MPL 2.0 to the Business Source License (BUSL). BUSL is source-available but restricts "competitive use" — broadly, you cannot offer Terraform as a hosted service competing with HashiCorp. The change provoked a backlash from the community and from competing IaC SaaS vendors.

Within weeks, the OpenTF Foundation (now OpenTofu) was formed under the Linux Foundation as an MPL 2.0 fork of Terraform 1.5. OpenTofu is binary-compatible with Terraform, supports the same provider ecosystem (with some divergence on registry semantics), and is now a fully independent project. As of mid-2026 OpenTofu has reached genuine production parity for most workloads and is the default choice for teams that need an OSI-approved licence.

The OpenTofu/Terraform split is the most consequential licensing event in DevOps history. For new projects in 2026, the answer is usually: use OpenTofu if licence purity matters or you operate at provider scale; stay on Terraform if you are a HashiCorp customer or use HCP Terraform's managed services.

Anatomy of a Terraform Module#

resource "aws_eks_cluster" "yobitel" {
  name     = "yobitel-h100"
  role_arn = aws_iam_role.cluster.arn
  version  = "1.31"

  vpc_config {
    subnet_ids = aws_subnet.private[*].id
  }
}

resource "aws_eks_node_group" "gpu" {
  cluster_name    = aws_eks_cluster.yobitel.name
  node_group_name = "h100"
  instance_types  = ["p5.48xlarge"]
  scaling_config {
    desired_size = 4
    min_size     = 0
    max_size     = 8
  }
}

Workflow Patterns#

• Local + remote state — small teams use local state, larger teams use S3 + DynamoDB locking, GCS, or HCP Terraform.
• GitOps via Atlantis or Spacelift — pull requests trigger `terraform plan`, merge triggers `terraform apply`.
• Policy as code — Sentinel (HashiCorp), Open Policy Agent (Rego), Checkov, tfsec, Terrascan — enforce guardrails before apply.
• Modules — versioned in private or public registries; the Terraform Registry hosts thousands of community modules.
• Workspaces — multi-environment management within one state backend (dev/staging/prod).

Limitations and Where Terraform Hurts#

Two pain points dominate production Terraform at scale. First, HCL's deliberate simplicity means complex logic is awkward — a typical workaround is generating HCL from a higher-level language (Terragrunt, jsonnet, or YAML). Second, state file management at scale is operationally heavy — locking, partial applies, refactoring resources between states, and importing existing infrastructure are all sources of incidents.

These pain points are part of why Crossplane (control-plane model) and Pulumi (real language) have grown — both address one or both of these issues differently.

Where Terraform Still Wins#

Terraform's installed base is enormous, the provider ecosystem is wider than any alternative, and the talent pool is the largest in IaC. For most teams in 2026 the right answer is still Terraform (or OpenTofu) for foundational infrastructure, with Crossplane layered on top for continuously-reconciled platform abstractions. Yobibyte uses this exact pattern: Terraform/OpenTofu provisions the base account, Crossplane runs the platform.