The new Infrastructure-as-Code battleground

The new Infrastructure-as-Code battleground

For most of the last decade, Infrastructure as Code (IaC) has been predictable. Terraform dominated multi-cloud estates, while AWS CloudFormation and CDK, Azure ARM/Bicep and Google Cloud Deployment Manager served single-cloud platforms. Teams standardised, wrote modules, and treated the tooling as solved.

That assumption no longer holds.

HashiCorp’s move to the Business Source License (BSL) for Terraform, followed by its acquisition by IBM, has forced organisations to re-examine what they want from their IaC layer in the long term: not just features, but neutrality, governance and exit options. At the same time, OpenTofu, Pulumi and Crossplane have matured into credible alternatives rather than side projects.

From the outside, this can look like fragmentation. In practice, it’s a reset – and it is changing what “good” IaC skills look like in the market.

Terraform and OpenTofu: same model, different governance

Terraform still offers a very strong technical model:

• Declarative desired state with a clear plan/apply lifecycle

• HashiCorp Configuration Language (HCL), optimised for readability and code review

• A deep provider ecosystem across major clouds and SaaS platforms

• Mature state-management patterns for complex, multi-account estates

OpenTofu effectively preserves that model while moving governance into an open, foundation-backed project. For most engineering teams, the day-to-day workflow is almost identical; the real divergence is strategic. Terraform is now an IBM-owned product with a source-available licence. OpenTofu keeps the HCL ecosystem but reduces the risk of a single vendor’s commercial decisions reshaping your control plane.

From a hiring perspective, this matters less at a “can they write HCL?” level and more at the level of platform strategy. Organisations that commit to OpenTofu signal that they want Terraform’s ergonomics without tying themselves tightly to IBM’s roadmap.

Cloud-native stacks: strong, but opinionated

The vendor-native stacks remain first-class options for single-cloud estates:

• AWS CloudFormation and CDK

• Azure ARM/Bicep

• Google Cloud Deployment Manager

They tend to win on early support for new services, tight integration with identity and monitoring, and clear governance models for central cloud teams in regulated environments. The trade-off is obvious: these stacks push you deeper into a given cloud’s way of thinking. For many enterprises that is acceptable; for organisations that treat multi-cloud optionality as a requirement, it is a constraint that needs offsetting elsewhere.

Pulumi: IaC as software

Pulumi starts from a different premise: infrastructure should be expressed in the same general-purpose languages engineers already use – TypeScript, Python, Go, C#, Java – and should share the same tooling: test frameworks, linters, IDEs and CI pipelines.

Technically, Pulumi keeps the benefits most people like in Terraform:

• A desired-state model with previews before changes are applied

• Providers across major clouds and common SaaS platforms

• Support for multi-environment and multi-account setups

The difference is how you structure the code. Teams can build internal platform libraries that expose high-level constructs (“production API”, “analytics pipeline”) instead of low-level resources. Infrastructure changes can be unit-tested and statically analysed the same way as application code.

That has consequences for hiring. Pulumi-heavy environments tend to look for software engineers with strong cloud fundamentals, rather than operations profiles who happen to know one DSL. Longer term, that usually gives organisations more flexibility in how they evolve their platforms.

Crossplane: Kubernetes as control plane

Crossplane extends Kubernetes with Custom Resource Definitions and controllers so that external infrastructure – databases, networks, cloud services – is modelled as Kubernetes resources and reconciled continuously. In Kubernetes-centric organisations with mature GitOps workflows, this offers a very clean story: one API, one reconciliation model, one pipeline.

It is not, however, a universal answer. Crossplane assumes Kubernetes is already the centre of gravity. For many platforms, it will sit alongside Terraform/OpenTofu or Pulumi rather than replace them entirely.

How teams are deciding in 2025

Across Trust In’s DevOps, SRE and platform searches we see four consistent decision axes:

• Ownership – platform-led organisations lean towards HCL (Terraform/OpenTofu) or vendor templates; product-led teams often prefer Pulumi or CDK.

• Cloud posture – single-cloud roadmaps align with native stacks; multi-cloud or hybrid strategies favour cross-platform tools.

• Kubernetes maturity – where K8s is the core platform, Crossplane becomes viable; elsewhere it often adds unnecessary complexity.

• Governance and licensing – the BSL shift and IBM acquisition make open governance and neutral licensing a first-order concern rather than an afterthought.

Where this points next

If you strip away branding and history, the long-term requirements most organisations describe are consistent: cloud neutrality, minimal single-vendor dependency, and an IaC model that aligns with how their engineers already build software.

On that axis, two approaches stand out.

OpenTofu keeps the Terraform mental model and ecosystem while reducing vendor risk. Pulumi aligns the IaC layer with mainstream software engineering practice and gives platform teams powerful abstraction and testing tools. Both remain cloud-neutral, and both are easier to reconcile with a “no single choke point” governance view than a proprietary, IBM-owned Terraform.

Terraform, especially inside large enterprises already invested in the HashiCorp stack, is not going away any time soon. But if you are choosing a foundation today with a five- to ten-year horizon, the combination of OpenTofu for HCL workflows and Pulumi for “infrastructure as software” increasingly looks like the more robust bet.