Why Terraform Falls Short for Platform Engineering (and Kubernetes Wins)

Key takeaways:

• Terraform is not the problem — it’s the wrong tool for a self-service platform: manual apply per change, no native API, no continuous reconciliation.
• Kubernetes + KRM + CRDs turn infrastructure into a self-service API: request a database, bucket, or cache with a single YAML — no tickets.
• Even Kelsey Hightower has stated Terraform isn’t suited for building cloud-provider-style control planes . -Field-reported KPIs from teams that made the switch: +50% developer productivity, −36% lead time, +40% software quality (Puppet State of DevOps, Gartner).

Do you practice DevOps or Cloud today? Then you’ve lived this: you’re shipping a critical feature, but everything stops because you need a Jira ticket to provision a database, an S3 bucket, or any other cloud service. Welcome to TicketOps — a pattern that creates bottlenecks, silos, and quietly kills the agility your teams spent years building.

Let’s be blunt: the celebrated principle “you build it, you run it” too often becomes “you build it, someone else queues it, and maybe one day you get to run it.” The result is wasted time, frustrated developers, and stalled innovation.

Why Terraform is not suited for Platform Engineering

Terraform is popular and works well for provisioning resources occasionally — but it was never designed to be the engine of a self-service platform. Three structural gaps explain why:

• Manual cycle — a terraform apply is required for every change. Not viable for dynamic, constantly evolving resources.
• No native API — you can’t easily expose infrastructure as self-service through a simple API.
• No continuous reconciliation — Terraform doesn’t automatically drive infrastructure back to its desired state when it drifts.

In short, for a genuine platform-as-a-service, Terraform hits its ceiling fast.

Kubernetes + KRM + CRDs: the new self-service model

Kubernetes is no longer just a container orchestrator — it’s a universal control plane for your entire infrastructure. The mechanism is the Kubernetes Resource Model (KRM) plus Custom Resource Definitions (CRDs), which let you manage anything declaratively.

Imagine this:

• Need a database? Apply a YAML.
• Need a Cloud Storage bucket? Another YAML.
• Want a Redis cache? That same YAML pattern again.

This is pure self-service, with zero tickets, powered by Kubernetes and projects like Crossplane, AWS Controllers for Kubernetes (ACK), and Google Config Connector.

During his talk at Control Plane Day with Crossplane 2023, Kelsey Hightower — Developer Advocate at Google and a defining voice in the cloud-native community — put it plainly:

“Terraform is not suited for building control planes similar to those of major public cloud providers.”

Coming from an engineer whose talks and live demos have guided modern infrastructure practice for a decade, that carries real weight.

Level up: expose everything via REST, gRPC, and SDKs

The goal of this architecture is simple: give teams autonomy without losing control. Kubernetes acts as the central control plane on top of KRM, and product, DevOps, and development teams provision what they need through a single API — exposed over REST, gRPC, or even WebSocket.

This API isn’t a gadget — it becomes the standard entry point, usable from client libraries (Go, Python, JavaScript, Java), CLI tools, or an internal portal like Backstage. Teams stop waiting on tickets, and delivery cycles accelerate.

In the background, the platform continuously reconciles resources against your cloud providers and key tools (Google Cloud, GitLab, Kubernetes, Vault, Okta…). While teams self-serve, your Platform Engineering, SRE, and DevSecOps groups enforce company-wide security rules, reliability standards, and best practices. You industrialize the cloud at scale without friction: governance stays central, teams gain speed — the best of both worlds.

Better still, you can expose your services as a first-class API. From your CRDs you can auto-generate protobuf definitions, then expose REST or gRPC endpoints and ship SDKs for every language your developers use. They won’t even need to write YAML — they’ll call your platform API directly. The modern developer’s dream becomes real:

• Zero tickets
• Instant provisioning
• Transparent GitOps integration

The numbers speak for themselves

Here are concrete KPIs reported by organizations that made the leap from TicketOps to self-service platforms:

• 🚀 +50% developer productivity
• 🕒 −36% lead time between commit and production
• 🧘 +40% improvement in software quality
• 📈 75% of large enterprises expected to adopt this model by end of 2025 (Gartner)

These figures come from the field — notably the Puppet State of DevOps report and Gartner analysis. Your mileage will vary, but the direction is consistent: less waiting, faster delivery, higher quality.

Goodbye TicketOps, hello self-service

The era of endless Jira tickets for simple provisioning is over. Adopt Kubernetes as the foundation of your Platform Engineering — with KRM and CRDs — and give your teams a genuinely self-service experience. Your infrastructure becomes agile, scalable, and API-first, and your developers will thank you (maybe even with cookies 🍪).

So — ready to leave Terraform behind for the parts it was never built for, and step into an API-first future with Kubernetes? You won’t regret it. 🚀

Conclusion: how Edixos can support you

At Edixos, we know a cloud platform is more than a stack of tools: it must be built to last, evolve, and fit each organization’s specific needs. Our expertise goes far beyond deploying Kubernetes clusters:

• We write custom Kubernetes controllers that automate your business processes and specific needs.
• We integrate powerful composition engines like Crossplane and Kro to turn Kubernetes into a true multi-cloud provisioning engine.
• We work with existing controllers such as Config Connector (KCC), which natively expose major cloud providers’ services through Kubernetes CRDs.
• We build complete, API-first platforms — exposing your services via REST, gRPC, and multi-language SDKs — to unify access and accelerate adoption.

What we offer is unique know-how to industrialize your cloud platforms: governance, security, and self-service at scale. This is exactly the kind of work behind our decade-long Kubernetes journey. If your ambition is a robust platform that aligns innovation, agility, and control, we have the building blocks and the experience to make it happen.

Let’s talk about your advanced Kubernetes challenges

Are you looking to automate operations, model your business processes, or industrialize deployments on Kubernetes? Let’s discuss your challenges and see how the API Machinery can bring you speed, reliability, and scalability.

Related reading

• Kubernetes FinOps: cutting cluster cost without breaking prod — the same platform, measured on spend.
• AI SRE agents for autonomous Kubernetes operations — the same platform, measured on reliability.

Frequently asked questions:

Is Terraform bad? Should we stop using it?

No. Terraform is excellent for provisioning infrastructure occasionally and for one-shot changes. It falls short as the engine of a self-service platform because it needs a manual apply per change, exposes no native API, and doesn't continuously reconcile drift — the three things a platform control plane requires.

What is the Kubernetes Resource Model (KRM)?

KRM is the declarative API pattern Kubernetes uses: you declare desired state in YAML, and controllers continuously reconcile reality to match. With Custom Resource Definitions (CRDs), KRM extends beyond containers to databases, buckets, and any cloud service — making Kubernetes a universal control plane.

How do Kubernetes and CRDs enable self-service infrastructure?

CRDs let platform teams expose cloud resources as simple YAML APIs. A developer applies a manifest for a database or cache, and a controller (via Crossplane, ACK, or Config Connector) provisions and reconciles it automatically — no Jira ticket, no manual Terraform run, with RBAC and policy enforced centrally.

What is TicketOps and why is it a problem?

TicketOps is the anti-pattern where developers must open a ticket to provision any infrastructure, then wait for another team to fulfill it. It breaks the 'you build it, you run it' principle, creates bottlenecks and silos, and slows delivery. Self-service platforms on Kubernetes eliminate it.

Can I expose Kubernetes infrastructure as a REST or gRPC API?

Yes. Because CRDs are API definitions, you can generate protobuf from them and expose REST, gRPC, or WebSocket endpoints, plus multi-language SDKs (Go, Python, JavaScript, Java). Developers consume the platform through a single API — or tools like Backstage — instead of writing YAML.