Big Picture Overview
Modern systems don’t run on “just code.” They run on infrastructure: networks, databases, load balancers, Kubernetes clusters, IAM roles, message queues, and more. In the cloud, these are all created through APIs—meaning your infrastructure is effectively software-controlled.
But there’s a catch:
- Clicking around in a cloud console doesn’t scale.
- Manual changes are hard to track and easy to forget.
- Recreating the same environment twice often produces “almost the same” results.
- Auditing “who changed what” becomes painful.
Terraform exists to solve this.
Terraform is a tool for Infrastructure as Code (IaC): you describe the infrastructure you want in files, and Terraform figures out how to create or update the real infrastructure to match that description.
Think of it as:
- A planner that computes what needs to change
- A safe executor that applies changes
- A repeatability mechanism that makes environments reproducible
Terraform fits into modern systems as the provisioning layer: it builds and evolves the cloud resources that your applications run on.
Core Concepts Explained Simply
1) Desired State (the “target picture”)
You describe what you want (e.g., “a database,” “a VPC,” “a Kubernetes cluster”), not the step-by-step commands to build it.
Terraform compares:
- Desired state (your config files)
vs - Actual state (what exists in the cloud)
Then it computes changes to move reality toward your desired state.
2) Providers (the “adapters”)
Terraform doesn’t create infrastructure by itself. It uses providers, which are plugins that know how to talk to external APIs.
Examples:
- AWS / Azure / Google Cloud
- Kubernetes
- GitHub
- Datadog
Provider = “Terraform, but for this platform.”
3) Resources (the “things” you create)
A resource is an infrastructure object Terraform can manage:
- a VM instance
- a database
- an IAM policy
- a load balancer
Resources are the building blocks.
4) State (the “memory”)
Terraform needs a reliable record of what it previously created so it can safely update it later. This record is called state.
State answers questions like:
- “Which exact database instance did we create?”
- “What attributes did it have last time?”
- “What changed since then?”
State is powerful—and sensitive. Treat it like production metadata.
5) Plan → Apply (the “preview then execute” loop)
Terraform typically works in two phases:
- Plan: shows what it would change (a preview/diff)
- Apply: actually performs those changes
This separation is one of Terraform’s biggest safety features.
6) Modules (the “reusable blueprints”)
A module is a reusable bundle of Terraform configuration.
Instead of rewriting “VPC + subnets + routing” every time, you package it into a module and reuse it across environments.
7) Drift (when reality diverges)
If someone manually changes cloud resources outside Terraform (console edits, scripts, etc.), reality can drift away from the Terraform definition.
Terraform can often detect drift during planning—then either fix it or force you to resolve it intentionally.
How It Integrates into a System
Terraform doesn’t serve end users directly. It sits “beside” your runtime system and shapes the infrastructure that runtime depends on.
Interaction with clients or users
Users interact with your application (web/mobile/API). Terraform is not in that request path.
But Terraform indirectly affects users by provisioning:
- load balancers and DNS (availability)
- autoscaling and capacity (performance)
- networks and security (risk)
- data stores (durability)
Interaction with backend services
Backend services run on compute platforms (VMs, containers, Kubernetes). Terraform:
- creates the compute layer
- wires service-to-service networking
- configures ingress, security groups, IAM roles
- sets up observability integrations
Interaction with data stores or external systems
Terraform can provision and configure:
- databases
- caches
- queues/topics
- object storage
- external SaaS integrations (monitoring, DNS, SCM tooling)
Interaction with cloud/infrastructure components
This is Terraform’s core domain:
- networks (VPCs, subnets, routing, firewall rules)
- clusters and node pools
- load balancers, certificates, DNS
- IAM identities and permissions
Plain Text Diagrams for Visualization
1) High-level architecture (Terraform’s place in the ecosystem)
+--------------------+ +-----------------+ +----------------------------+
| Engineer / CI | ---> | Terraform | ---> | Cloud / External Platforms |
| (changes IaC files)| | (plan + apply) | | (AWS/Azure/GCP/SaaS/K8s) |
+--------------------+ +-----------------+ +----------------------------+
^ |
| v
+------------------+
| State Backend |
| (remote + lock) |
+------------------+
+--------------------+ +--------------------------------------------+
| Clients / Users | ----> | Running System (services + data stores) |
+--------------------+ +--------------------------------------------+
Key idea: Terraform is a control-plane tool, not part of the live request path.
2) Data/request flow (change lifecycle: plan → review → apply)
Engineer
|
v
Commit IaC change (desired state) ---> Git Repo / PR
|
v
CI Pipeline runs:
- validate
- plan (preview)
|
v
Terraform PLAN
/ \
v v
Read State Read Cloud (refresh)
Backend APIs (actual infra)
\ /
v v
Diff / Plan Output
|
v
Review / Approval
|
v
Terraform APPLY
|
+--> Update Cloud resources
|
+--> Update & lock State
|
v
Audit trail / status
Key idea: plan gives visibility; apply makes controlled changes; state enables safe collaboration.
3) Key integration points (where Terraform touches other parts)
+----------------------+
| CI/CD System |
+----------+-----------+
|
v
+------------------+ +----------------------+ +------------------------+
| Module Registry | ---> | Terraform | ---> | Cloud Provider APIs |
| (internal/shared)| | (providers + config) | | (networks, compute...) |
+------------------+ +----------+-----------+ +------------------------+
|
+---------------------> +-------------------+
| | Kubernetes API |
| +-------------------+
|
+---------------------> +-------------------+
| | SaaS APIs |
| | (DNS/Monitoring/SCM|
| +-------------------+
|
+<--------------------> +-------------------+
| | State Backend |
| | (remote + locking) |
| +-------------------+
|
+---------------------> +-------------------+
| Secrets Manager |
+-------------------+
NOTE: Prefer referencing
secrets rather than
storing them in state.
Key idea: Terraform orchestrates changes across cloud + platform + tooling via APIs.
Common Use Cases (2–3 Realistic Scenarios)
1) Provisioning a cloud platform for a microservices system
You need consistent infrastructure for:
- networking
- Kubernetes or container hosting
- ingress + certificates
- managed databases + caches
- IAM roles and least-privilege permissions
Terraform makes this repeatable across environments.
2) Multi-environment consistency (dev/stage/prod) with controlled differences
You want:
- the same architecture everywhere
- but different sizes/limits per environment
Terraform + modules lets you reuse blueprints while parameterizing differences.
3) Organization-wide baseline infrastructure and compliance
You want consistent guardrails:
- logging enabled
- encryption enforced
- mandatory tags for cost allocation
- network segmentation standards
Terraform helps standardize and audit these changes over time.
Trade-offs and Limitations
What Terraform is good at
- Consistency and repeatability across environments
- Change visibility via plan (blast-radius preview)
- Cross-platform provisioning (cloud + SaaS + Kubernetes)
- Auditability when paired with Git and PR reviews
What Terraform is bad at
- Runtime orchestration (it doesn’t handle per-request behavior)
- Imperative workflows with complex step-by-step logic
- Secrets management naïvely (state can expose sensitive data)
- Replacing deployment tools (it’s not a CI/CD or app deploy tool)
Common mistakes (and overuse patterns)
- Using Terraform like configuration management
Terraform provisions infrastructure. OS/app configuration is often better suited to other tools. - One giant Terraform stack
Massive “everything in one folder” setups become hard to evolve safely. - Manual console edits
Creates drift and undermines repeatability. - Leaking secrets into state
State is not a secrets vault. Reference secrets rather than embedding them. - Coupling app releases tightly to infra changes
Most deployments should not require infra changes every time.
How This Fits into an Architect’s Mental Model
As an architect, think of Terraform as:
Terraform = “The infrastructure compiler”
- Input: a declarative description of infrastructure intent
- Output: a computed set of changes to real infrastructure
- Benefit: consistent, reviewable infrastructure evolution
Use Terraform when:
- The thing you’re managing is long-lived infrastructure
- You want reviewable change control
- You want reproducible environments
- You need consistent baseline policies/guardrails
Avoid (or limit) Terraform when:
- The problem is primarily runtime behavior
- You’re managing app deployment details that belong in deployment tooling
- You’re handling secret-heavy workflows without a careful design
Quick heuristic
Ask:
- “Is this a durable infrastructure object?” → Terraform is likely a fit.
- “Do we want plan/review before changes?” → Terraform shines.
- “Is this runtime behavior or app release mechanics?” → Terraform is probably not the right tool.
One-paragraph summary
Terraform helps teams manage cloud and platform infrastructure the way they manage code: versioned, reviewable, repeatable, and automated. It’s best used for stable foundations—networks, compute platforms, data stores, identity, and integrations—where predictable change control matters. It’s not a runtime tool, not a deployment system, and not a secrets vault. For architects, it’s most useful as the provisioning layer that turns infrastructure from “tribal knowledge” into an engineered, auditable system.
My Notes 