The Core Dispute: Real Code vs. a Domain-Specific Language
The most fundamental disagreement comes down to how you should write infrastructure. Terraform uses HashiCorp Configuration Language (HCL), a declarative language created specifically for defining resources. Senior engineers who favor this approach argue
that HCL is purpose-built, highly readable, and forces a clear separation between infrastructure and application logic. This makes it easier for operations-focused teams to manage. In contrast, Pulumi lets engineers use general-purpose programming languages like Python, TypeScript, or Go. Proponents argue this is a massive advantage. Teams can use familiar tools like IDEs, linters, and testing frameworks, and handle complex logic, loops, and abstractions without the constraints of a DSL. CloudFormation sits in its own category, using verbose JSON or YAML, which many find cumbersome for anything but the simplest tasks.
State Management: Who Holds the Map?
Every IaC tool needs a “state file” — a map of the resources it manages in the real world. How this is handled is a major point of contention. Terraform requires you to explicitly configure and manage your state, often storing the file in a cloud bucket and setting up locking mechanisms to prevent conflicts. This gives teams granular control but also adds operational overhead; a lost or corrupted state file is a serious incident. Pulumi uses a similar model but steers users toward its managed Pulumi Cloud service, which handles state storage, locking, and encryption automatically, reducing the day-to-day burden. CloudFormation completely abstracts this away; AWS manages the state of your stacks internally, which is simpler but offers less direct control and visibility. The disagreement here is between total control (Terraform), managed convenience (Pulumi), and native abstraction (CloudFormation).
Ecosystem and Lock-In: Breadth vs. Depth
A frequent topic of debate is vendor lock-in. CloudFormation is, by design, an AWS-only tool. For teams fully committed to the AWS ecosystem, this provides the deepest and most immediate integration with new services. For everyone else, it’s a non-starter. Both Terraform and Pulumi are proudly multi-cloud. Terraform has the largest and most mature ecosystem, with thousands of providers for different clouds and services, making it the de facto standard for heterogeneous environments. Pulumi also supports multiple clouds, often by using a bridge to Terraform's providers, but its native provider ecosystem is smaller. The disagreement pits CloudFormation's deep, native integration against Terraform’s unparalleled breadth and Pulumi's developer-centric flexibility in a multi-cloud world.
Testing and Reusability: Engineering Discipline vs. Configuration
Senior engineers often clash over what it means to write high-quality, reusable infrastructure. With Pulumi, because you're using a real programming language, you can write unit and integration tests for your infrastructure using standard frameworks like Pytest or Jest. This appeals to those who want to apply software engineering discipline to infrastructure. Terraform has its own approach to reusability through “modules,” which are shareable, versioned packages of HCL. While powerful, testing them often involves third-party tools and a different workflow than application code. The argument is essentially about what constitutes a better abstraction: a software library (Pulumi) or a declarative configuration module (Terraform). Engineers with a development background often prefer Pulumi's model, while those from an operations background may find Terraform's modules more straightforward and reliable.
