Introduction

Managing infrastructure manually works fine while the environment is small. As servers, networks, databases, and other services grow, problems with repeatability, documentation, standardization, and change control start to appear.

Infrastructure as Code, or IaC, treats infrastructure as versionable, reproducible code.

Instead of relying on a sequence of clicks in a console, we describe the desired state of the infrastructure in files.

What is Infrastructure as Code?

IaC is an approach in which infrastructure resources are defined through files that can be versioned, reviewed, and executed automatically.

A manual workflow might look like this:

  1. Create a network.
  2. Create subnets.
  3. Create a machine.
  4. Configure access rules.
  5. Repeat everything in another environment.

With IaC, this configuration can be described in code and reapplied.

Benefits

  • Replicability: the same code can create similar environments.
  • Versioning: changes can be tracked through Git.
  • Review: changes can go through pull requests.
  • Automation: pipelines can run validations and plans.
  • Standardization: teams can follow common structures and conventions.

What is Terraform?

Terraform is an Infrastructure as Code tool based on declarative configuration, developed by the company HashiCorp.

Instead of specifying each step the tool should execute, we describe the desired outcome.

For example, conceptually:

resource "example_server" "app" {
  name = "app-server"
  size = "small"
}

Terraform interprets this configuration, compares the desired state with the known state of the infrastructure, and determines which changes are necessary.

Imperative vs. declarative

An imperative approach tends to answer:

“Run these actions in this order.”

A declarative approach answers:

“I want my infrastructure to have these characteristics.”

This difference is fundamental to understanding Terraform.

The basic cycle

Terraform’s basic flow is:

Code
  ↓
terraform init
  ↓
terraform plan
  ↓
terraform apply
  ↓
Infrastructure

When the configuration changes, Terraform recalculates the differences.

But before writing infrastructure, it’s important to understand Terraform’s mental model.

The most important concepts are:

Terraform
├── Configuration
├── Providers
├── Resources
├── Data Sources
├── State
└── Modules

In this article, we’ll focus on the fundamental concepts.

Configuration

Configuration is the set of .tf files that describes the desired infrastructure.

Example:

resource "example_server" "app" {
  name = "app-server"
}

The code doesn’t necessarily describe every step of creation. It declares how we want the resource to be.

Providers

Terraform doesn’t natively know every cloud service, SaaS, or API that exists.

Providers are plugins that allow Terraform to interact with these APIs.

Examples of provider categories:

  • Cloud providers
  • Kubernetes
  • GitHub
  • DNS
  • Monitoring
  • Databases and other services

A provider makes resources and data sources available for use in the configuration.

Resources

Resources represent objects that Terraform can create, change, or remove.

Conceptual example:

resource "example_server" "app" {
  name = "app-server"
}

The structure is:

resource "TYPE" "NAME" {
  configuration
}

This resource’s address in Terraform will be:

example_server.app

Data Sources

Data Sources allow us to query existing information without necessarily managing that object’s lifecycle.

Conceptually:

data "example_network" "default" {
  name = "default"
}

The distinction is important:

  • Resource: usually represents something Terraform manages.
  • Data Source: usually represents information that Terraform queries.

State

State is one of the most important parts of Terraform.

It records information about the resources Terraform is managing and helps relate the configuration to the actual infrastructure.

We shouldn’t treat it as just “some database.” It’s part of Terraform’s management mechanism.

We’ll study State in depth later on.

The mental flow

We can simplify execution like this:

Desired configuration
        +
Known state
        ↓
Terraform calculates changes
        ↓
Provider executes operations
        ↓
State is updated

This cycle explains much of the tool’s behavior.

Declarative doesn’t mean magic

Terraform decides which operations it needs to perform, but that doesn’t eliminate the need to understand dependencies, destructive changes, state, and provider characteristics.

That’s why terraform plan is an essential step.

Next article

In the next article, we’ll install Terraform and start getting our hands dirty.