Why We Looked Beyond Terraform: Crossplane vs Terraform at Scale

This article is part of a five-blog series where we share a customer use case — how we reimagined their cloud infrastructure strategy with Crossplane, GitOps, and a hybrid Terraform approach.

Setting the Stage

Terraform got us here. But when our client’s platform grew to 50+ microservices across multiple regions, it started to crack. State files clashed, ephemeral environments dragged, and drift became a silent enemy. That’s when we looked beyond — and found the missing piece in Crossplane.

AWS Cloud isn’t just changing how companies run applications — it’s redefining what’s possible. What starts as a simple setup for Dev, QA, Stage, and Production can quickly balloon into a sprawling ecosystem:

• Global reach across regions
• Microservices sprawl with dozens of infra stacks
• Ephemeral test environments spun up at will

This speed is powerful — but the wrong tools collapse under scale. That’s exactly what happened in our client’s case.

The Customer’s Challenge

A leading digital commerce platform, operating across 35+ cities, was preparing to scale globally. Their platform connected customers and merchants across fine dining, spas, and travel experiences — while also offering merchants a powerful branding channel to reach nearby customers.

The platform ran on a microservices-heavy architecture with more than 50 services, each requiring:

• An elastic load balancer.
• Auto-scaling application instances.
• Databases → PostgreSQL for transactions, MongoDB and Elasticsearch for scale, HBase for personalization.
• Apache Kafka for event-driven pipelines.

The next phase of growth demanded:

1. Multi-region deployments to serve global audiences.
2. Ephemeral environments so developers could spin up short-lived infra per feature or pull request.
3. Automation and standardization to reduce operational overhead and complexity.

At first, Terraform was the tool of choice. But as the system grew, so did the pain points.

Takeaway: Terraform handled the first phase well, but scaling exposed cracks.

Where Terraform Fell Short

Terraform has proven itself as a robust tool for building both small and large-scale, complex infrastructure. However, as our client’s environment grew and became more dynamic, we encountered practical challenges:

State file complexity → With multiple teams and regions, managing and securing Terraform state files became fragile and error-prone. Ownership disputes and state locking often slowed collaboration.

Slow ephemeral environments → Developers faced delays when spinning up and tearing down short-lived environments because of state locking/unlocking, which wasn’t designed for high-frequency, Git-driven workflows.

Fire-and-forget model → Terraform provisions infrastructure and exits. If an AWS resource drifts or is modified outside Terraform, it won’t self-correct until the next apply.

In short, Terraform remained excellent for foundational and static infrastructure, but it struggled in scenarios demanding continuous reconciliation, rapid ephemeral environments, and high developer velocity — exactly where Crossplane excels.

Terraform automates creation, but Crossplane automates continuity. That shift — from provisioning to reconciliation — made all the difference.

In short, Terraform remained excellent for foundational and static infrastructure, but it struggled in scenarios demanding continuous reconciliation, rapid ephemeral environments, and high developer velocity — exactly where Crossplane excels.

Why Crossplane and Not Others

Before finalizing Crossplane, we evaluated multiple Infrastructure-as-Code (IaC) and control-plane tools — Pulumi, AWS CDK, and Terraform Cloud.
Each had strengths, but none solved the “always in sync” problem:

• Pulumi / AWS CDK → Great for developers, but tightly coupled with specific programming languages, not Kubernetes-native YAML.
• Terraform Cloud → Simplified state management but still lacked real-time reconciliation.
• Crossplane → Runs inside Kubernetes, treating cloud infrastructure as part of the same control loop that keeps pods healthy.

Ecosystem Evolution: How Infra as Code Evolved

Terraform (State File) → Pulumi (Code SDK) → CDK (Language SDK) → Crossplane (Kubernetes-native Reconciliation)

Takeaway: Terraform automates creation, but Crossplane automates continuity. That shift — from provisioning to reconciliation — made all the difference.

Comparative Study: Crossplane vs Terraform at Scale

When we compared Crossplane and Terraform, one distinction stood out: execution model.

• Terraform is like a hammer → strong for building once, but it stops there.
• Crossplane is like a pilot → always watching, continuously adjusting, keeping the system on course.

That continuous reconciliation loop is the critical advantage that makes Crossplane ideal for global, dynamic infrastructures.

Why This Matters

• No state files → Kubernetes itself becomes the source of truth.
• Drift prevention → infra never drifts away from the desired config.
• Auditability & rollbacks → with GitOps tools like ArgoCD, every change flows through Git.
• Developer velocity → ephemeral infra can be spun up safely, without affecting shared state.

Takeaway: Terraform is a provisioning tool. Crossplane is a management plane. At a global scale, that difference is game-changing.

Continuous Reconciliation: The Missing Piece

The “aha moment” was realizing Terraform lacked continuous reconciliation.

Kubernetes ensures pods match their declared state. Crossplane extends the same principle to cloud infra:

• Drift prevention → infra always synced
• Multi-region parity → manifests apply consistently
• Ephemeral safety → PR infra managed via Git

This was the missing piece in our puzzle.

Takeaway: Crossplane brings Kubernetes-style reconciliation to infra — always on, always in sync.

Why We Chose Crossplane Managed Resources Directly

We didn’t start with abstractions (XRDs). Instead, we went straight to Crossplane Managed Resources (MRs):

• Faster onboarding for VPCs, EKS, and RDS
• Fine-grained transparency
• Governance enforced via Kyverno, RBAC, and secure ProviderConfigs. 

Takeaway: Starting with MRs gave us speed without losing control — fast adoption with governance built in.

Our Long-Term Hybrid Vision

We didn’t throw Terraform away. Instead, we embraced a hybrid model:

• 90% Crossplane → reconciliation, GitOps, ephemeral infra
• 10% Terraform → complex or unsupported resources

Takeaway: Crossplane powers the lifecycle; Terraform handles the edge cases.

Conclusion

Looking beyond Terraform wasn’t rejection. It was recognition of its limits at scale.

For a platform with global reach, 50+ microservices, and ephemeral infra needs, Crossplane’s reconciliation model was the missing piece.

With this decision, we laid the foundation for a GitOps-native infra strategy that:

• Scales globally
• Prevents drift
• Boosts developer velocity

Next: Blog 2 – Designing a Hybrid Crossplane Architecture, where we share the blueprint behind our production-ready hybrid model.