The Complete Guide to Terraform: The Core Tool and Practices of Infrastructure as Code

What Is Terraform

Terraform is an open-source Infrastructure as Code (IaC) tool developed by HashiCorp. On GitHub, it has accumulated over 49,000 stars and 10,660 forks, gaining as many as 168 new stars in a single day, and it has long held a top spot in popularity rankings within the DevOps and cloud-native space.

In a nutshell: Terraform lets you create, change, and manage infrastructure in a safe and predictable way. It abstracts the APIs of various cloud services and platforms into declarative configuration files that can be shared, reviewed, and version-controlled by teams just like code.

Terraform GitHub project homepage

Terraform is developed in Go—a consistent technology choice across HashiCorp's product line. Go's static compilation lets Terraform be packaged as a single binary with no runtime dependencies, greatly simplifying distribution and deployment. Its goroutine mechanism enables parallel calls to multiple Provider APIs when processing complex dependency graphs, significantly improving the efficiency of large-scale infrastructure orchestration. HashiCorp's Vault, Consul, Nomad, and other products are all built in Go, forming a highly consistent technology stack that shares underlying libraries and toolchains.

Core Philosophy: Declarative Configuration

The Shift from Imperative to Declarative

Traditional operations rely on imperative actions: engineers execute commands step by step to set up servers, configure networks, and deploy applications. This approach is error-prone and difficult to reproduce or maintain over the long term.

Terraform's declarative approach is fundamentally different—you simply describe the "desired end state" in a configuration file, without worrying about "how to get there step by step." Terraform automatically calculates the difference between the current state and the target state, and generates a clear execution plan.

The core idea of declarative configuration stems from the concept of idempotency in functional programming—no matter how many times it runs, the same input always produces the same output. This makes Terraform's apply operation inherently idempotent: repeatedly applying the same configuration keeps the system state unchanged, without accumulating side effects. In contrast, imperative shell scripts, when run repeatedly, often lead to problems such as duplicate resource creation or configuration stacking. The declarative model completely decouples "what to do" from "how to do it," keeping the engine-level implementation details transparent to users—this is precisely why systems like Kubernetes and SQL widely adopt the declarative paradigm.

The Core Value of Infrastructure as Code

The rise of IaC is inseparable from the popularization of cloud computing. In the traditional data center era, infrastructure changes often required physical operations, and the demand for automation was limited. But in the cloud era, API-driven resource management made it possible to "describe servers with code." Beyond Terraform, representative IaC tools include AWS CloudFormation, Ansible, and Pulumi, each with its own focus—CloudFormation is deeply tied to the AWS ecosystem, Ansible excels at configuration management, and Pulumi supports writing infrastructure logic in general-purpose programming languages such as Python and TypeScript. With its multi-cloud support and declarative syntax, Terraform stands out in this arena.

Codifying infrastructure as IaC brings the mature practices of software engineering directly into operations work:

Version control: All infrastructure changes are tracked through Git and can be rolled back at any time
Code review: Changes are reviewed by the team before going live, effectively reducing the risk of misoperation
Reproducibility: The same configuration stays consistent across development, testing, and production environments
Team collaboration: Working together based on a unified configuration completely resolves the "environment inconsistency" problem

Terraform's Workflow

Terraform's standard workflow consists of three phases:

Write configuration: Use HCL (HashiCorp Configuration Language) to describe the required resources
Preview the plan: Run terraform plan to compare the current state with the desired state and generate a change preview
Apply changes: After confirming everything is correct, run terraform apply to actually implement the resource changes

Before executing apply, Terraform builds all resources and their dependencies into a Directed Acyclic Graph (DAG). Each node in the graph represents a resource, and each edge represents a dependency. Terraform automatically analyzes which resources can be created in parallel (no dependencies) and which must run sequentially (explicit or implicit dependencies exist)—for example, a VPC must be created before subnets, and an EC2 instance can only be configured after its security group is ready. This DAG-based scheduling mechanism not only maximizes execution efficiency but also fundamentally prevents creation failures caused by incorrect dependency ordering. Engineers can explicitly declare non-obvious dependencies using meta-arguments such as depends_on to intervene in scheduling behavior.

HCL: A Configuration Language Designed for Infrastructure

HCL (HashiCorp Configuration Language) is a configuration language HashiCorp designed specifically for its toolchain, balancing human readability with machine parseability. Compared to JSON, HCL supports comments, variable interpolation, and a more concise syntax; compared to YAML, it provides a stronger type system and greater expressiveness. HCL is not a Turing-complete programming language—this is a deliberate design trade-off: limiting the complexity of loops and conditional logic keeps configuration files predictable. Terraform 0.12 introduced a major upgrade to HCL, bringing a stricter type system that significantly improved the maintainability of complex modules.

The State File: The Core Mechanism for Predictable Changes

Throughout the process, Terraform continuously records the actual state of managed resources through a state file, which is the key mechanism enabling "predictable changes."

Terraform's state file (terraform.tfstate) is essentially a JSON file that records the actual state and metadata of all managed resources, serving as the "mapping bridge" connecting configuration files with real cloud resources. When plan is executed, Terraform compares the differences between the state file and the configuration file, rather than querying the cloud API directly each time—this improves performance while reducing API call costs. However, storing state files locally poses a race-condition risk in team collaboration scenarios. Production environments typically store state in remote backends such as S3, Azure Blob, or Terraform Cloud, and use tools like DynamoDB for state locking to prevent state corruption caused by concurrent operations.

This "preview—confirm—execute" workflow significantly improves the safety of infrastructure operations. Before modifying a production environment, engineers can clearly see which resources will be created, modified, or destroyed, greatly reducing the risk of unexpected outcomes.

Multi-Cloud Support and Ecosystem Advantages

A Rich Provider Plugin Ecosystem

One of Terraform's most competitive capabilities is its vast Provider ecosystem. Whether it's mainstream public clouds like AWS, Azure, and Google Cloud, or Kubernetes, Docker, and even various SaaS platforms, there are corresponding Provider plugins available.

Providers are the core extension mechanism of the Terraform ecosystem. Each Provider is essentially a gRPC plugin that communicates with the core engine through the Terraform Plugin SDK, translating HCL configurations into API calls for the corresponding platform. Providers are published publicly on the Terraform Registry and downloaded automatically when the terraform init command is run. The AWS Provider is the most mature example, with over a million lines of code supporting hundreds of AWS resource types. The quality of a Provider directly determines the depth of Terraform's support for a given platform—officially maintained Providers are usually more reliable, while community-maintained Providers may lag in features or have compatibility issues, so selection should take into account their maintenance activity and update frequency.

This means teams can use a unified syntax and workflow to manage hybrid infrastructure spanning multiple cloud platforms—avoiding the risk of vendor lock-in while reducing the multi-platform learning cost for operations teams.

License Change: From Open Source to Source-Available

Worth noting is that Terraform is now a "source-available" tool rather than open-source software in the traditional sense. In 2023, HashiCorp changed its license from MPL 2.0 to the BSL (Business Source License).

The BSL was first proposed by MariaDB, and its core mechanism is: for a certain time window (typically 4 years), commercial competitive use is restricted, after which it automatically converts to an open-source license. HashiCorp's switch triggered a strong backlash from the open-source community, with the core controversy being that cloud service providers integrating Terraform into their own products faced legal uncertainty.

In August 2023, a community led primarily by former HashiCorp employees announced the creation of OpenTofu (formerly OpenTF), which gained the support of the Linux Foundation and became a truly open-source alternative to Terraform. The birth of OpenTofu is one of the most representative community fork events in the open-source world in recent years—its predecessor, the OpenTF Manifesto, was jointly launched by companies with Terraform as their core business, such as Gruntwork, Spacelift, and env0, and within just a few days it gathered support from over 100 companies and hundreds of individuals. OpenTofu is fully compatible at the code level with Terraform 1.x's HCL syntax and state format, allowing existing users to migrate at low cost. The Linux Foundation's endorsement gives it a neutral governance structure, avoiding the risk of being controlled by a single commercial entity. OpenTofu has now achieved independent feature iteration, and some features (such as state file encryption) even lead ahead of the official Terraform version, forming genuine technical competition.

In 2024, HashiCorp itself was acquired by IBM for approximately $6.4 billion, further adding to the uncertainty of the Terraform ecosystem and driving continued growth in OpenTofu's community adoption. For enterprise users, understanding license boundaries is crucial in commercial-competitor development or large-scale commercialization scenarios.

Use Cases and Getting-Started Advice

Terraform is especially well-suited for the following scenarios:

Medium-to-large enterprises needing to uniformly manage complex multi-cloud environments
Engineering teams pursuing infrastructure standardization and automation
Organizations hoping to genuinely implement DevOps best practices

For beginners, it's recommended to start with simple resources on a single cloud platform (such as creating a virtual machine), and gradually dive into advanced concepts like state management and modules. In production environments, be sure to configure remote storage and locking mechanisms for the state file to avoid state conflicts during multi-person collaboration.

Summary

With its declarative configuration, multi-cloud Provider support, and mature tooling ecosystem, Terraform has become the de facto standard in the Infrastructure as Code space, and its nearly 50,000 GitHub stars are strong evidence of its industry standing.

Although the license change brought some controversy—and gave rise to OpenTofu, a competing, truly open-source fork—Terraform's advantages in technical maturity and practical usability remain outstanding. Whether you're a newcomer just getting into IaC or an architect seeking a unified multi-cloud management solution, Terraform is well worth learning and practicing in depth.