Originally published on my Hashnode blog.
Introduction
In this series, I’ll cover how Terraform works behind the scenes—not just the “how to use it,” but the why and what’s really happening under the hood.
Terraform has become a core tool in the DevOps toolkit. These days, almost no infrastructure shop runs without it.
There are plenty of blogs, articles, and tutorials showing how to use Terraform, and for many engineers, that’s enough. But if you’re like me—someone who isn’t comfortable until you really understand what’s going on—this series is for you.
Let’s dig in and truly unbox Terraform, together.
Why Terraform?
Let’s “start with why,” as Simon Sinek suggests.
Before Terraform, there were quite a few tools for infrastructure provisioning—but most were imperative, platform-specific, or came with a steep learning curve. Terraform changed the game by making infrastructure management simple, powerful, and accessible.
Terraform is cloud-agnostic: it enables you to manage multi-cloud and even non-cloud resources all in one place, thanks to its massive provider ecosystem (there’s even a provider for ordering pizza!).
One of Terraform’s biggest strengths is state management. Instead of guessing what’s deployed, Terraform keeps a detailed state file. This acts as a single source of truth and lets you plan safe, predictable changes every time.
Modularity is at the heart of Terraform. Modules make it easy to roll out standardized, production-ready infrastructure and stay DRY (Don’t Repeat Yourself).
Terraform scales for everyone—from a solo engineer at a startup to 100+ infrastructure engineers pushing code in monorepos. Because everything is defined as code, collaboration is seamless through version control. For larger teams, HCP Terraform adds secure access controls, a shared registry, and robust workflow management—so nobody steps on anyone else’s toes.
High-Level Architecture
Let’s take a look at the high-level architecture of Terraform.
At the center of this setup is the Engineer—you, the platform engineer or SRE—who defines the infrastructure requirements using simple, human-readable .tf files (Terraform configuration).
These configuration files are fed into the Terraform Core engine, which acts as the brain of the entire workflow. The core engine is responsible for interpreting your configuration and coordinating the process of infrastructure provisioning.
Terraform Core then interacts with two major components: the State Backend and the Providers.
The State Backend is responsible for storing and tracking the current state of your infrastructure, whether that’s in a local file or a remote backend such as Amazon S3, Google Cloud Storage (GCS), or Consul.
On the other side, Providers are plugins that serve as translators between Terraform and the actual infrastructure platforms—such as AWS, GCP, Azure, and many more. Providers communicate directly with real-world resources, making the necessary API calls to provision, update, or delete infrastructure as defined in your configuration.
This architecture ensures a clean separation of concerns:
- Terraform Core manages logic and orchestration
- The State Backend keeps track of what exists
- The Providers handle direct communication with your target environments
Wow, that looks simple, right?
That’s exactly the magic of Terraform—it’s intentionally built to keep the complexity hidden behind clear abstractions, so you get a clean, approachable architecture.
If you’re a platform engineer, here’s a key takeaway: abstraction is your superpower when building developer tools. The easier and more intuitive you make things, the more productive (and happy!) your users will be. Keep this principle in mind as you design your own platforms and tools!
Typical Terraform Workflow
Terraform is built around a clear, predictable workflow:
- init: Initializes your working directory, downloads providers, and configures backend storage.
- plan: Creates an execution plan—shows what will change without making any modifications.
- apply: Executes the plan, provisioning and updating resources to match your configuration.
- destroy: Cleanly removes all managed resources defined in your Terraform project.
You can think of these steps as the core “flow” every Terraform run follows, making infrastructure changes predictable, repeatable, and easy to review.
How Terraform is Revolutionizing Infrastructure Management
In the early days of our cloud migration, we started with Google Cloud Deployment Manager. At the time, it did the job and helped us automate our initial deployments. But as our infrastructure grew, we ran into some natural limitations: we needed more imperative scripts for custom tasks, handled post-deployment steps in Python or Bash, and integrating with CI/CD pipelines took extra effort. Troubleshooting issues and reusing deployment patterns across projects was possible, but not always straightforward.
Moving to Terraform was a turning point. Suddenly, infrastructure became truly modular and version-controlled. Every change could be planned, reviewed, and applied with confidence, thanks to Terraform’s plan and apply workflow. Modules let us standardize best practices and scale automation across different projects. With its state management, environments became predictable and consistent. We’ve managed not just new infrastructure, but also performed complex, high-impact changes—even in stateful, long-running systems—by leveraging Terraform. The ability to safely plan, delete, and rebuild components using existing configurations gave us a level of reliability and control that simply wasn’t possible before.
It’s also worth noting that Google Cloud has announced the deprecation of Deployment Manager, with support ending in March 2026. The recommended path forward is to migrate to Google’s new Infrastructure Manager, which is built to work natively with Terraform configurations behind the scenes. This means you can keep using your existing Terraform knowledge, workflows, and modules, while integrating more deeply with Google Cloud’s ecosystem.
Looking back, it’s clear that Terraform didn’t just replace a tool—it brought a new mindset to how we manage and evolve infrastructure. That’s the real revolution.
Preview of What’s Next
You might be thinking—this doesn’t feel like a “deep dive” just yet! We’re just getting warmed up. In the upcoming parts of this series, we’ll move beyond the architecture and start exploring the internals of Terraform—how it actually operates under the hood.
Starting with Part 2, we’ll take the core Terraform workflow and dissect each phase, beginning with a deep look at what happens during terraform init. We’ll break down the plugin system, backend initialization, and other foundational processes, peeling back the layers so you understand not just what Terraform does, but how and why it does it.
Stay tuned—the real deep dive into Terraform internals starts next!
About the Author
Suryaprakash Lakshmanan is a Cloud Engineer and Architect specializing in SRE, DevOps, true automation, and scalable infrastructure design.
Connect on LinkedIn for more discussions and technical deep dives.
Top comments (0)