By As organizations scale to hundreds of Kubernetes clusters, database provisioning becomes ungovernable. Application developers spin up data services across scattered AWS accounts, enterprise databases, and on-premises systems, and platform teams lose visibility entirely. Without a separation between database operations and application development, governance collapses and operational risk grows with every new cluster.
In this interview on TFiR, Julian Fischer, CEO at anynines, walks through how Klutch addresses the database governance and orchestration gap that platform teams face when managing data services across large-scale, multi-cluster Kubernetes environments.
Guest: Julian Fischer, CEO at anynines
Show: TFiR
Here is what every platform engineer and SRE needs to know.
Technical Deep Dive
Q: What specific problem does Klutch solve for platform teams managing data services across Kubernetes clusters?
Julian Fischer, CEO at anynines, explains that as organizations grow, they accumulate more Kubernetes clusters and eventually need to serve hundreds or thousands of application developers running databases inside those clusters. The core problem is that the responsibility for running data services and their automation should not fall on application developers. Klutch solves this by providing a central control plane that separates database operations from application development, so platform teams can manage all data service integrations centrally while developers retain local self-service access.
“You don’t want to put the burden of running data services and their automation on the shoulder of application developers.” — Julian Fischer, CEO, anynines
Q: How does Klutch’s architecture separate database operations from application development?
Fischer describes a model where a central control plane manages all data service automation integrations. Application clusters install a lightweight extension that gives developers local self-service database provisioning. When a developer declares a database from within their Kubernetes cluster, that intent is replicated to the control plane and reconciled with the actual automation backend, whether that is a managed cloud service or an on-premises system.
“All the application developers have to do is install a lightweight extension to the application cluster and they get that local self-service declaring a database, there you go from within your Kubernetes cluster.” — Julian Fischer, CEO, anynines
Q: How does Klutch handle provisioning a managed database like AWS RDS from within a Kubernetes cluster?
Fischer uses AWS RDS as a concrete example. A developer declares an RDS database from within their application cluster using the standard Kubernetes interface. Klutch replicates that intent to the control plane, which delegates the request to the AWS API. The database then appears local to the application cluster, meaning developers attach applications to it and manage it from the same place they declared it, without seeing or managing the remote delegation.
“It appears as if the database was local in your application cluster, because that’s where you control the database, that’s where you declare, that’s where you attach applications to it and it’s delegated to the control plane and delegated to the AWS API eventually.” — Julian Fischer, CEO, anynines
Q: Why do existing tools like AWS billing fail to provide adequate database visibility for platform teams?
Fischer points out that AWS billing can tell a platform team who is using RDS databases, but only within that single cloud provider’s accounting model. When RDS usage is scattered across many AWS accounts, and when organizations also run enterprise databases, custom-built services, or databases from other vendors, those tools break down entirely. The result is that platform teams have no unified view of who is running what data service and where across the full topology.
“If you also integrate services that you’ve created on your own or enterprise databases or other database vendors, then things get messy. And this is where Klutch shines.” — Julian Fischer, CEO, anynines
Q: What environments does Klutch support beyond AWS?
Fischer states that while AWS is the starting point, Klutch is designed to extend to other cloud platforms over time. Critically, it also supports on-premises deployments, making it applicable to organizations with hybrid infrastructure. Fischer frames Klutch as an orchestration and governance entity that works across cloud and on-premises environments from a single control plane.
“You can do that on AWS, later you will be able to do that on other platforms too. And you can also do that on premises. It becomes this orchestration and governance entity that’s been missing for years.” — Julian Fischer, CEO, anynines
Resources & Documentation
- anynines, developer of Klutch, the central control plane for managing data services across Kubernetes clusters
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: For those who may not be familiar, and since we are headquarters, the audience is of course platform engineers, SREs and of course everybody’s talking about AI these days. What specific problem does Klutch solves for platforming, managing data services at a scale?
Julian Fischer: So in general like everybody is using Kubernetes and the bigger the organization gets, the more Kubernetes clusters they are likely to have. Now, if you provision a lot of kubernetes clusters and you’re trying to serve hundreds or even thousands of application developers running databases inside of Kubernetes clusters, usually in the entire pattern, you don’t want to put the burden of running data services and their automation. You don’t want to put that responsibility on the shoulder of application developers. So when you’re building in house developer platforms, you need to separate database operations from application development. And that is basically where Klutch comes into the game, because we allow to have a central control plane where you manage all the integrations of all the data service automation that your company wants to use and expose to application developers. And all the application developers have to do is install a lightweight extension to the application cluster and they get that that local self service declaring a database, there you go from within your Kubernetes cluster and this intent is then replicated towards the control plane and reconciled with the actual automation backend. So for example, you can, with any hub on AWS as an example, declare an RDS database and it will be created for you. And it appears as if the database was local in your application cluster, because that’s where you control the database, that’s where you’re declared, that’s where you attach applications to it and it’s delegated to the control plane and delegated to the AWS API eventually. So the application developer doesn’t see that it’s remote, while the platform team has the central overview. So they will be asking, okay, who uses RDS databases? Well, if your RDS usage is scattered across many AWS accounts, you have a topology in your aws. You can use AWS billing in order to find out. But if you also integrate services that you’ve created on your own or enterprise databases or other database vendors, then things get messy. And this is where Klutch shines because it provides you that, you know, overview and you can do that on AWS later you will be do that on other platforms too. And you can also do that on premises. It becomes this orchestration and governance entity that’s been missing for years.
