By Platform teams managing data services across Kubernetes, Cloud Foundry, and AWS operate without a consistent abstraction model, forcing engineers to handle provisioning, binding, and configuration independently per service and per environment. The Open Service Broker API introduced useful primitives, but its rigidity prevented teams from expressing service-specific configuration depth without breaking the abstraction contract. The result is fragmented platform tooling that does not scale cleanly across organizations of different sizes or provisioning strategies.
In this interview on TFiR, Julian Fischer, CEO at anynines, covers how Klutch introduces a flexible CRD-based abstraction layer for data services, how the new Tenant entity maps to real multi-cloud provisioning structures, and what this means for platform teams building on Kubernetes and AWS.
Guest: Julian Fischer, CEO at anynines
Show: TFiR
Here is what every platform engineer building on Kubernetes and multi-cloud data services needs to know.
Technical Deep Dive
Q: Where do the abstractions in Klutch come from and why were they chosen?
Julian Fischer, CEO at anynines, explains that the abstractions in Klutch, specifically service instances, service bindings, and service plans, originate from the Open Service Broker API developed within the Cloud Foundry ecosystem. These primitives proved valuable in production environments and anynines carried them forward into Klutch rather than inventing new constructs. The key change was relaxing the strict structural requirements the original API imposed, giving platform teams more flexibility without abandoning proven concepts.
“The abstractions in Klutch themselves, like a service instance, service binding, service plans, originate from the Open Service Broker API from the Cloud Foundry ecosystem. These abstractions have proven to be valuable.” — Julian Fischer, CEO, anynines
Q: How does Klutch implement service instances differently from the original Open Service Broker API?
In Klutch, a service instance is implemented as a Kubernetes Custom Resource Definition. Teams can determine the structure of that CRD themselves, provided the resource is identified as a service instance. Fischer notes that the original Open Service Broker API was strict about how service instances should be structured, and Klutch deliberately relaxes that constraint. This allows platform teams to maintain a consistent abstraction across services while retaining the ability to express highly custom configurations where needed.
“A service instance is basically a CRD and you can determine the structure of the CRD as you wish, as long as it’s called a service instance.” — Julian Fischer, CEO, anynines
Q: How does Klutch handle services that are similar but not identical, such as native Postgres versus AWS RDS Postgres?
Fischer uses the example of anynines Postgres versus RDS Postgres to illustrate how Klutch balances shared abstractions with service-specific depth. For services that are functionally similar, the service instance specifications will look largely the same, giving platform teams a consistent interface. When a service instance is taken to the edge with highly custom configuration, the specs will diverge, and Fischer states explicitly that this is acceptable behavior by design. The abstraction layer does not force artificial uniformity where genuine differences exist.
“If you have anynines Postgres versus RDS Postgres, they are more or less the same and the abstractions will look more or less the same. But if you take a service instance to the edge with highly custom configuration, these specs will differ and that’s okay.” — Julian Fischer, CEO, anynines
Q: What is the new Tenant entity being introduced in Klutch and why does it matter for platform teams?
Fischer describes an active change underway in Klutch that introduces a first-class Tenant entity. When building platforms, teams need to represent tenants explicitly, and Klutch allows this to be declared in a fully declarative manner. Fischer gives the example of a tenant that has two AWS accounts, a service account and an EKS account, which the platform needs to represent and provision correctly. The Tenant abstraction makes this relationship explicit rather than implicit or manually managed.
“If you’re building platforms you want to have a tenant. You want to tell your platform declaratively that’s a tenant.” — Julian Fischer, CEO, anynines
Q: What does a tenant declaration look like in practice on a9s Hub?
Fischer explains that implementations of what it means to declare a tenant will be available on a9s Hub. A tenant declaration could represent something like a user pool in AWS Cognito, or it could trigger the creation of AWS accounts alongside that. Fischer is clear that the right implementation depends on the organization’s size and its existing strategy for provisioning Kubernetes and EKS clusters, meaning the Tenant abstraction is intentionally flexible rather than prescriptive.
“It could be something like a user pool in AWS Cognito, or it could be along with that also creating those AWS accounts. It always depends on how big your organization is and how your provisioning strategy of Kubernetes and EKS looks like.” — Julian Fischer, CEO, anynines
Resources & Documentation
- anynines, provider of Klutch and managed data service platform tooling for Kubernetes and multi-cloud environments
- Open Service Broker API, the Cloud Foundry ecosystem specification that originated the service instance, service binding, and service plan abstractions used in Klutch
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: When we look at of course anynines, you are managing data services across Kubernetes, of course Cloud Foundry, you mentioned AWS. How does Klutch provide that unified abstraction layer? So for teams, that’s abstracted.
Julian Fischer: So the abstractions in Klutch themselves, like a service instance, service binding service plans originate from the Open Service Broker API from the Cloud Foundry ecosystem. These abstractions have proven to be valuable. However, the Open Service Broker API was a bit strict about how they should look like. This is something we relaxed in Klutch. So a service instance is basically a CRD and you can determine the structure of the CRD as you wish. As long as it’s called a service instance. It allows you some sort of abstraction among different services, while it allows you also to be very custom about each service. In other words, if you have anynines Postgres versus RDS Postgres, they are more or less the same and the abstractions will look more or less the same. But if you take a service instance to the edge with highly custom configuration of a service instance, these specs will differ and that’s okay. So we bring well proven abstractions to the table. There is a change ongoing in Klutch where we also introduce a new entity called Tenants. Because if you’re building platforms you want to have a tenant. Earlier I said you have per tenant, for example two AWS accounts, a service account and an EKS account that is basically a tenant and you want to tell your platform declaratively that’s a tenant. So we are going to introduce a tenant abstraction in Klutch and on a9s Hub there will be then implementations on what does it mean to declare a tenant. It could be something like a user pool in AWS Cognito, or it could be along with that also creating those AWS accounts. It’s always a question how big your organization is and how your provisioning strategy of Kubernetes and EKS looks like because that varies depending on the organization size.
