In this exclusive interview with Swapnil Bhartiya at TFiR, Julian Fischer, Founder and CEO at anynines, discusses Klutch’s architecture and roadmap, the commercial a9s Hub product for AWS and on-premises, the evolving role of multi-tenancy and governance in platform engineering, Cloud Foundry’s continued enterprise relevance, and the introduction of CF AppStage as a Backstage-native UI for Cloud Foundry environments.

Klutch: Decoupling Database Operations from Application Development

As Kubernetes adoption scales across large organizations, the number of clusters grows rapidly — and with it, the operational challenge of managing data services consistently across all of them. Platform teams building internal developer platforms (IDPs) need a way to expose database provisioning to application developers without pushing the complexity of data service automation onto every individual team.

Klutch solves this by introducing a centralized control plane that sits above individual application clusters. Developers install a lightweight extension on their application cluster and interact with data services through Kubernetes-native APIs — with no visibility into the underlying provisioning mechanics.

Q: What specific problem does Klutch solve for platform teams managing data services at scale?

Julian Fischer: “When you’re building in-house developer platforms, you need to separate database operations from application development. Klutch allows you to have a central control plane where you manage all the integrations of all the data service automation your company wants to use and expose to application developers. All the application developers have to do is install a lightweight extension to the application cluster, and they get local self-service — they declare a database from within their Kubernetes cluster.”

This intent-based model means a developer can declare an RDS database from within their EKS application cluster, and Klutch reconciles that declaration through the control plane to the AWS API — all transparently. From the developer’s perspective, the database appears local. From the platform team’s perspective, all provisioning, governance, and cost attribution are visible from a single pane.

Q: What happens when data services are scattered across many AWS accounts without a control plane?

Julian Fischer: “If your RDS usage is scattered across many AWS accounts, you have a topology in your AWS that you can use AWS billing to find out about. But if you also integrate services you’ve created on your own, or enterprise databases, or other database vendors, things get messy. This is where Klutch shines — it provides that overview. You can do that on AWS, later on other platforms too, and you can also do that on-premises. It becomes the orchestration and governance entity that’s been missing for years.”

a9s Hub: Enterprise-Grade Klutch for AWS and On-Premises

While Klutch is open source and freely deployable, production enterprise deployments require additional integration work, security hardening, and tested automation backends. This is the space a9s Hub occupies. Built on top of open-source Klutch, a9s Hub adds commercial integrations, enterprise support, and opinionated deployment patterns aligned with AWS’s Well-Architected Framework and on-premises Kubernetes environments using a9s Data Services.

Q: How does the commercial a9s Hub relate to the open-source Klutch project?

Julian Fischer: “Klutch itself solves the problem — it provides a central control plane, a set of abstractions like service instances, service bindings, backup and restore, and allows you to create your own integrations. But you have to deploy it on your own and secure it on your own, which is not trivial in enterprise cases. There’s no two versions of Klutch — there are just add-ons that extend the functionality. The orchestration and the framework, that’s Klutch, and it’s open source.”

For AWS environments, a9s Hub aligns with the Well-Architected Framework’s typical account topology — where each tenant has a dedicated EKS application cluster account and a separate service account. When a Klutch client is installed on an application cluster, it provisions data services into the corresponding tenant’s service account, maintaining the account boundary model required by enterprise compliance and cost isolation frameworks.

Multi-Tenancy, Governance, and the New Tenant Abstraction

One of the most significant near-term developments in Klutch is the introduction of a declarative Tenant abstraction. This addition reflects what anynines has observed across large enterprise deployments: the definition of a “tenant” varies significantly by organization, but the need to declare and manage tenants programmatically is universal.

Q: How does Klutch approach multi-tenancy given that the definition of a tenant varies so much across organizations?

Julian Fischer: “A tenant could mean different things in different platforms. As a first approximation in large enterprise clients, it usually means a set of AWS accounts — but it’s also imaginable to make a different flavor of tenant where a tenant is not an AWS account or a set of AWS accounts, but just a share on an EKS cluster. Klutch starts with giving you abstractions, and there will be a blueprint — defining what types of tenants you have, what services you want to integrate, here’s a set of existing integrations, or here is a way to write your own. It becomes a reference model on how to approach this problem in a more generic manner.”

Practically, the Tenant abstraction enables platform teams to declare that a tenant corresponds to an AWS Cognito user pool, a pair of AWS accounts (EKS cluster + service account), or an isolated VPC — depending on organizational topology. This makes it possible to automate tenant onboarding and offboarding as a first-class platform operation within Klutch, rather than a manual out-of-band process.

Q: How do Klutch’s abstractions compare to the original Open Service Broker API from Cloud Foundry?

Julian Fischer: “The abstractions in Klutch — 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. 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 some abstraction among different services while allowing you to be very custom about each service.”

Cloud Foundry: Still Standing, and Still Relevant

Julian Fischer has been a vocal defender of Cloud Foundry’s operational efficiency, and at KubeCon Amsterdam 2026, his position has not softened. While Kubernetes dominates mindshare and product investment, Fischer makes a pointed distinction between what Kubernetes offers in terms of flexibility versus what Cloud Foundry delivers in terms of operational economy — particularly for organizations running large numbers of regulated, compliance-bound applications.

Q: How is the Cloud Foundry user base evolving, and where does anynines position itself in that transition?

Julian Fischer: “Cloud Foundry, to this day, is a turnkey solution for building an application developer platform. You have a marketplace, you have the Open Service Broker API, you have a9s Data Services — you put it on anynines Cloud Foundry with a9s Data Services, and it runs and runs and runs. There’s no outage here and outage there because you have to maintain this and maintain that. You don’t have to train each team on how to run Cloud Foundry. It’s centrally provided, and it works at scale. If you take that operational efficiency and calculate how much overhead you have per app, there is no better solution for running a large number of apps than Cloud Foundry. To this day, I still believe that.”

Fischer acknowledges the market reality clearly: Kubernetes is the larger, more dynamic product market. But he differentiates between market attractiveness and technical superiority for specific workloads. For organizations with hundreds of developers building compliant enterprise applications, Cloud Foundry’s automation depth and operational stability remain difficult to replicate with a pure Kubernetes stack.

CF AppStage: Backstage as the New Front End for Cloud Foundry

Alongside its Klutch work, anynines has been building CF AppStage — a modern, Backstage-based replacement for Stratos UI, the aging open-source web UI for Cloud Foundry. Stratos accumulated significant technical debt, making feature development and security maintenance increasingly uneconomical. CF AppStage rebuilds the UI on Cloud Foundry API v3 using Backstage as the platform frontend framework.

Q: What is CF AppStage and what gap does it fill in the Cloud Foundry ecosystem?

Julian Fischer: “CF AppStage is a Stratos UI replacement. It’s built on the Cloud Foundry API version three. It’s fast, easy to use. The team building CF AppStage is going to continue to build a similar UI framework for platform engineers as well as application developers for Klutch as well. So Backstage is basically the new front end for anynines platform — Cloud Foundry and a9s Data Services, but also for a9s Hub with Klutch and all the integrations.”

This move signals anynines’ intent to unify its Cloud Foundry and Kubernetes product lines under a single Backstage-native frontend layer — giving platform engineers and application developers a consistent UI experience regardless of whether their underlying platform is Cloud Foundry, EKS with a9s Hub, or a hybrid of both.