This chapter follows State data in Terraform. Choosing a tool is choosing a workflow: language, state model, ecosystem, and who maintains the core engine.
OpenTofu
OpenTofu is an open-source fork of Terraform maintained under the Linux Foundation. It targets compatibility: the same HCL, provider ecosystem, and familiar CLI commands (init, plan, apply). Many modules run unchanged.
Differences accumulate over time. OpenTofu has added features such as optional client-side state encryption and continued community-driven RFCs where HashiCorp’s roadmap diverges. Teams switch by installing the OpenTofu binary and keeping provider versions pinned; CI images and lock files should name which engine you standardize on.
OpenTofu is a strong fit when you want Terraform-like workflows under a fully open-source license without abandoning existing .tf repositories.
Pulumi
Pulumi defines infrastructure in general-purpose languages—TypeScript, Python, Go, C#, Java—instead of HCL. State, preview, and update loops resemble Terraform’s, but logic uses normal language features (loops, classes, unit tests).
Pulumi fits teams that already center on TypeScript or Python and want IaC beside application code, with Pulumi ESC and cloud integrations for secrets and policy. The tradeoff is a different toolchain and smaller shared-module ecosystem than the Terraform Registry, though Pulumi packages many GCP resources.
Use Pulumi when language-native abstraction matters more than HCL portability; use Terraform or OpenTofu when maximizing Registry modules and hiring familiarity with HCL.
Cloud-native provisioning tools
Hyperscalers ship first-party IaC:
| Tool | Platform | Notes |
|---|---|---|
| Google Cloud Infrastructure Manager | GCP | Deploys Terraform-compatible configurations with Google-managed execution; integrates with GCP IAM and org policies |
| AWS CloudFormation | AWS | YAML/JSON templates native to AWS; deep service coverage on AWS |
| Azure Resource Manager (Bicep) | Azure | Bicep compiles to ARM JSON; strong Azure integration |
On GCP, Infrastructure Manager suits organizations standardizing on Google-managed pipelines while keeping Terraform language. Multi-cloud or portable modules still favor Terraform/OpenTofu providers. Single-cloud shops sometimes pick native tools for tighter platform integration and support contracts.
Ansible and configuration management
Ansible configures software on hosts—packages, systemd units, config files—often over SSH or WinRM. It can call cloud modules to create VMs, but its strength is convergence on machines, not a persistent graph of cloud resources with centralized state locking.
A common pattern: Terraform or OpenTofu provisions networks, IAM, and VMs; Ansible configures what runs inside them (or use container images and startup scripts instead).
Choose Ansible when the problem is application deployment and OS state; choose Terraform-family tools when the problem is durable cloud resource lifecycle with plan/apply review.
Choosing a direction
| Need | Reasonable default |
|---|---|
| Portable HCL, Registry modules, large hiring pool | Terraform or OpenTofu |
| OSS engine with Terraform compatibility | OpenTofu |
| TypeScript/Python IaC with full language power | Pulumi |
| GCP-only, Google-managed apply | Infrastructure Manager |
| OS and app config after VMs exist | Ansible (often plus Terraform) |
This series focused on Terraform because of its breadth on Google Cloud and shared module ecosystem. The same architectural ideas—declarative desired state, reviewed plans, remote state—appear across tools with different syntax and governance.
Companion references: Terraform cheat sheet and Terraform glossary.
Check your understanding
Question 1 of 5
0 of 5 checked