By The Core Concept: Crossplane is a capable integration layer, but using it as the sole orchestration mechanism for data services at enterprise scale creates CRD overhead that collapses developer self-service — and most platform teams don’t discover this until they’re already deep in the architecture.
The Guest: Julian Fischer, CEO & Founder of anynines
The Bottom Line:
• Klutch‘s lightweight connector model is purpose-built for what Crossplane can’t do at scale — delivering self-service data provisioning across hundreds of Kubernetes clusters without CRD overhead
Speaking with TFiR, Julian Fischer of anynines defined the current state of Kubernetes data service orchestration — and why the ecosystem’s default answer, Crossplane, isn’t sufficient on its own.
WHAT IS THE CROSSPLANE SCALING PROBLEM?
Crossplane has earned genuine traction as a way to reconcile non-Kubernetes resources from within Kubernetes. Fischer acknowledges this — anynines uses Crossplane on the control plane side for writing backend integrations. But the problem surfaces when teams try to use it as the complete orchestration layer.
“If you have a marketplace that comprises many data services—different databases—and you want to expose them across a wide range of application clusters where developers get self-service capabilities, such as creating a service instance or a service binding—where you create a database and bind an application to it simply by declaring your intent—then in Crossplane, building such a client and installing it to expose that marketplace to developers and provide that self-service is quite resource-consuming.”
The underlying issue: every database type requires custom resource definitions installed on every application cluster. Across hundreds of clusters and dozens of database types, the CRD overhead becomes a significant infrastructure burden — and the developer experience degrades accordingly.
HOW KLUTCH SOLVES IT
Klutch introduces a clean architectural separation. The control plane — where integrations are written and governance lives — handles the heavy lifting. Application clusters receive a lightweight Klutch connector that can be rolled out to hundreds of clusters without meaningful overhead. Developers interact only with the lightweight extension, declaring their intent to provision a database the same way a Cloud Foundry user would: create service instance, create service binding, done.
Fischer also noted that Crossplane should not be the only integration technology used on the control plane side. anynines has written native Go operators for backends where Crossplane creates unnecessary friction — particularly around major version upgrades that force updates across all integrations simultaneously. With vibe coding lowering the barrier to writing Go, the utility of native operators is growing. Fischer also flagged KROW (Kubernetes Resource Orchestrator) as an emerging alternative worth watching for Klutch integrations.
BROADER CONTEXT: WHAT ANYNINES IS BUILDING
This clip is drawn from a longer conversation about a9s Hub — the commercial product built on top of open source Klutch. In the full interview, Fischer describes two primary enterprise use cases: a9s Hub for AWS, which maps to the AWS Well-Architected Framework’s multi-account topology and enables centralized governance across hundreds of AWS accounts and EKS clusters; and a9s Hub for On-Prem, designed for organizations in Europe facing digital sovereignty requirements running OpenStack or VMware infrastructure.
Both use cases share the same architectural foundation described in this clip: a Klutch control plane per region, lightweight extensions in application clusters, and a uniform developer experience for provisioning data services — whether those services are RDS, anynines-managed Postgres, or internally developed databases.
Watch the full TFiR interview with Julian Fischer here
