By Guest: Julian Fischer (LinkedIn)
Company: anynines
Show Name: KubeStruck
Topic: Kubernetes
Platform engineering teams face a fundamental tension in Kubernetes environments. Developers want instant access to databases and data services. Operations teams need control, security, and centralized oversight. Traditional approaches force you to choose one or the other.
📹 Going on record for 2026? We're recording the TFiR Prediction Series through mid-February. If you have a bold take on where AI Infrastructure, Cloud Native, or Enterprise IT is heading—we want to hear it. [Reserve your slot
Julian Fischer, CEO & Founder of anynines, has been thinking about this problem for years. His answer is Klutch—an open source data service orchestration framework that gives developers the illusion of local databases while keeping the actual automation separate and controlled.
The Core Problem: Data Services at Scale
As Kubernetes moves beyond simple container orchestration into full application development platforms, the data layer becomes critical. Fischer explains the shift: “In the past, it was more about lifting and shifting VM workloads. Now, there’s more traction among application developers using Kubernetes to run their web applications.”
This creates competition with platforms like Cloud Foundry, which have long offered developers self-service access to databases through service brokers and marketplaces. The question becomes: how do you replicate that experience in Kubernetes without sacrificing control?
The challenge intensifies when you’re managing dozens or hundreds of Kubernetes clusters. Each application team wants their own cluster. Each cluster needs access to databases—PostgreSQL, MySQL, Redis, whatever the application requires. But database operations, whether VM-based or container-based, are complex. They require specialized knowledge, careful capacity planning, and robust backup strategies.
Klutch’s Design Philosophy: Separation of Concerns
Klutch solves this through a deliberate architectural decision that Fischer says has received “zero pushback” from larger organizations: keep database automation outside application clusters.
“Database operations are kind of a tricky thing to do, and you want to keep them in a separate team,” Fischer explains. “So if you separate data service automation from application deployments, how do you enable local, on-demand self-service?”
The answer is a plugin architecture. Developers install Klutch into their application cluster. When they declare they need a database—a service instance in Kubernetes terms—Klutch handles the abstraction. The database gets provisioned, but not in the local cluster. It happens in a separate, controlled environment managed by the database team.
To the developer, it feels local. The connection strings appear in their environment variables. The database is immediately usable. But the actual provisioning, scaling, backup, and lifecycle management happens elsewhere.
The Control Plane: Orchestration at Scale
For organizations with many Kubernetes clusters, Klutch includes a control plane that becomes essential. “The Klutch control plane allows you to integrate any data service automation at once and expose this automation across all your Kubernetes clusters for all your application developers,” Fischer says.
This means the database team writes one integration—to PostgreSQL on VMs, to a Kubernetes operator, to AWS RDS, whatever the backend is. That integration immediately becomes available to every application cluster in the organization. Developers get consistency. Operations teams get visibility and control.
From Open Source to Production
Klutch launched as open source, and Fischer reports strong validation of the core design assumptions. The framework provides the abstractions and domain model. But it doesn’t include the actual automation backends.
That’s where a9s Hub comes in. The commercial offering extends Klutch with production-ready integrations: anynines Data Services for VM provisioning, Kubernetes operators for pod-based databases, and upcoming AWS integrations for services like RDS and S3.
“You actually need integrations with Klutch to solve the data service challenges faced by application developers,” Fischer explains. “That’s what a9s Hub is about.”
For platform engineering teams building internal developer platforms, this represents a pragmatic path forward. Start with the open source framework to validate the architecture. Add commercial integrations when you need production support and enterprise features.
What This Means for Platform Teams
The rise of platform engineering as a discipline reflects the maturation of Kubernetes. It’s no longer enough to give teams a cluster and kubectl access. Organizations need cohesive developer experiences that abstract infrastructure complexity while maintaining operational excellence.
Data services represent one of the hardest pieces of that puzzle. Databases are stateful, complex, and critical. Getting self-service right means balancing developer velocity with operational safety.
Klutch offers a model: maintain the separation between application and data layers, but make the boundary invisible to developers. Use a control plane to achieve consistency at scale. Integrate once, deploy everywhere.
For organizations managing multiple Kubernetes clusters—especially those also running Cloud Foundry or considering migrations—this approach addresses a real gap in the ecosystem. The alternative is often homegrown solutions that become maintenance burdens or vendor platforms that lock you into specific clouds.
As Fischer notes, the decision to adopt a framework like Klutch isn’t simple. It shapes how you design your entire application delivery experience. But for organizations at scale, the alternative—letting each team solve data services independently—leads to fragmentation, duplicated effort, and operational chaos.
