The Big Picture: When platform teams manage hundreds of Kubernetes clusters and dozens of AWS accounts, traditional data service orchestration tools collapse under the weight of multi-tenancy, compliance requirements, and cross-account complexity. The gap between what developers need — frictionless self-service provisioning — and what infrastructure can actually deliver is widening.

The Guest: Julian Fischer, CEO & Founder of anynines

Key Takeaways:

• Crossplane is useful for writing backend integrations but fails as the sole orchestration layer at enterprise scale — Klutch’s lightweight cluster extensions are purpose-built for this problem
• a9s Hub for AWS maps directly to the AWS Well-Architected Framework’s multi-account topology, enabling centralized platform governance while distributing service instances per-tenant
• The on-prem case is driven by data sovereignty pressure — particularly in Europe — where OpenStack-based environments need seamless Kubernetes and Cloud Foundry integration
• anynines is building the data service layer that both Cloud Foundry and Kubernetes need to serve as runtimes for AI agents that carry state

[expander_maker]

In a recent TFiR interview, Swapnil Bhartiya spoke with Julian Fischer, CEO & Founder of anynines, about the state of data service orchestration at enterprise scale — and why the tools most Kubernetes teams are relying on today won’t survive the demands of multi-cluster, multi-cloud, and AI-driven infrastructure.

THE PROBLEM WITH CROSSPLANE AT SCALE

Why Crossplane Fails as a Sole Orchestration Layer

Crossplane has earned real traction in the Kubernetes ecosystem as a way to reconcile non-Kubernetes resources from within Kubernetes. Julian Fischer acknowledges this directly — anynines uses Crossplane on the control plane side for writing backend integrations. But several customers that doubted Klutch was necessary and attempted to build a centralized control plane for data service orchestration using Crossplane alone ran into significant problems.

“If you have a marketplace that comprises a lot of data services — different databases — and you want to expose them across a wide range of application clusters where application developers get self-service, the way you know it if you were a Cloud Foundry user — create a service instance, create a service binding, declare your intent — in Crossplane, building such a client and then installing it so it exposes that marketplace to application developers, providing that self-service, is quite resource consuming.”

The core issue: custom resource definitions representing different databases and database instances must be introduced to each application cluster. At scale, this becomes untenable. Klutch solves this by providing a lightweight connector that can be applied to hundreds of Kubernetes clusters without causing significant overhead.

THE Klutch ARCHITECTURE

How anynines Separates the Control Plane from the Application Cluster

Klutch’s architecture draws a clean line between the control plane — where integrations are written and governance lives — and the application cluster — where developers interact with a lightweight extension. Platform teams install Klutch once per region on a managed Kubernetes cluster. Application clusters receive a small plugin. From there, developers can provision service instances declaratively, just as they would in Cloud Foundry.

A secondary finding: Crossplane should not be the only integration technology on the control plane side. anynines has written native operators for backends where Crossplane creates friction, particularly when major version upgrades force updates across all integrations. Fischer also flagged KRO (Kubernetes Resource Orchestrator) as an emerging alternative worth watching for writing Klutch integrations.

a9s Hub FOR AWS

Orchestrating Data Services Across Hundreds of AWS Accounts

The a9s Hub for AWS is a direct response to a recurring pattern Fischer’s team observed across large enterprises using the AWS Well-Architected Framework. The framework prescribes a topology where EKS clusters live in one type of account and data service instances — RDS, S3, and others — live in dedicated service accounts, with that pairing repeated per tenant. At scale, this produces hundreds of AWS accounts.

“You’re looking at hundreds of AWS accounts, and people would love to create RDS instances from those Kubernetes clusters spanning those AWS accounts — while the platform team needs to maintain an overview on where has been used what.”

The anynines solution: one Klutch control plane per region. The control plane uses lightweight extensions in each application cluster and introduces a tenant model — each tenant is declared with its associated AWS accounts. When a developer provisions a service, Klutch delegates the request, assumes the appropriate IAM role for that tenant’s account, and creates the service instance in the right place. The platform team retains full central visibility.

For teams with existing RDS infrastructure, anynines is building migration scripts capable of reading existing AWS topology — assuming Well-Architected compliance — and importing it into a9s Hub automatically.

a9s Hub FOR ON-PREM

Data Sovereignty and Hybrid Orchestration in OpenStack Environments

The on-prem case is shaped by a different set of pressures — primarily digital sovereignty, which has become a political priority across Europe. Organizations in this segment typically run OpenStack or VMware (with a strong trend toward OpenStack) and need data services that bridge Cloud Foundry and Kubernetes environments within their own network.

The challenge is networking: Cloud Foundry environments, data service instances running as VMs, and Kubernetes application clusters each live in separate networks. anynines addresses this with the anynines Network Connector — an implementation of the Network Connector Interface within Klutch that exposes any service, whether VM or container, to Kubernetes application clusters seamlessly.

AI WORKLOADS AND THE RUNTIME FOUNDATION

Why Cloud Foundry and Kubernetes Together Are the Right Foundation for Stateful AI

Fischer’s view on AI infrastructure is direct: AI needs a runtime, and if code carries state, it needs data services. Cloud Foundry, in Fischer’s assessment, remains underrated for running large numbers of AI agents at scale — the economy of scale is significant, and the developer experience for binding apps to services is proven. Kubernetes is unavoidable but leaves teams without guardrails on data service orchestration.

“I think AI needs a runtime. If you run code that runs in the cloud, it needs to run somewhere — and it either runs in Cloud Foundry or it runs in Kubernetes. And if it carries state, it needs data services. And if you have data services, they need to be orchestrated.”

a9s Hub is designed to be the orchestration layer underneath both — modular enough to support Kubernetes-only, Cloud Foundry-only, or hybrid deployments, and extensible enough to integrate internally developed services alongside AWS-managed and anynines-managed databases.

[/expander_maker]