By Kubernetes multi-tenancy is not a single architecture decision. Organizations running hundreds of developers on five clusters, teams isolating workloads inside shared VPCs, and enterprises assigning dedicated AWS accounts per tenant are all solving the same problem in fundamentally different ways. A platform that assumes one model breaks every other one.
In this interview on TFiR, Julian Fischer, CEO at anynines, breaks down how tenant definitions vary across real enterprise deployments and how the Klutch framework is designed to absorb that variability without imposing a fixed topology.
Guest: Julian Fischer, CEO at anynines
Show: TFiR
Here is what every platform engineer and Kubernetes architect needs to know.
Technical Deep Dive
Q: Why is Kubernetes multi-tenancy so hard to standardize across organizations?
Julian Fischer, CEO at anynines, explains that what counts as a tenant is determined by the specific way an organization deploys and uses Kubernetes, not by a universal standard. Some organizations run five clusters for hundreds of developers, a topology Fischer does not recommend but acknowledges can work for particular workloads. Because the definition of a tenant shifts with each organization’s infrastructure choices, any platform layer must be flexible enough to accommodate radically different topologies without forcing a single model.
“What a tenant is, is to be defined by the particular way how you use your infrastructure in the first place and how you deploy Kubernetes and how you use Kubernetes.”
Julian Fischer, CEO, anynines
Q: What are the real differences between VPC isolation and network-only tenant separation in Kubernetes?
Fischer draws a direct contrast between two common isolation patterns he observes in production environments. In some organizations, application clusters share a production AWS account but are separated into distinct VPCs, providing strong network boundaries at the account level. In others, clusters are separated by network configuration alone, without the additional boundary of a VPC. Neither approach is universally correct; the right choice depends on the organization’s workload characteristics, compliance requirements, and existing cloud account structure.
“In some other clients they are separated with networks, but not with VPCs.”
Julian Fischer, CEO, anynines
Q: How does the Klutch framework handle different tenant definitions without requiring a custom build each time?
Fischer describes Klutch as a framework that provides abstractions rather than a fixed solution, designed to be embedded across diverse infrastructure scenarios through the a9s Hub integration layer. A tenant in Klutch can map to a dedicated AWS account, a set of AWS accounts, or a shared partition on an EKS cluster, depending on what the organization needs. The framework is evolving into a reference model that guides teams through explicit design decisions: which tenant types to define, which services to integrate, and how to write custom integrations when existing ones do not fit.
“Klutch starts with giving you abstractions and there will be more or less of a blueprint where you follow a designated path defining what different types of tenants do you have.”
Julian Fischer, CEO, anynines
Q: Is Klutch a prescriptive platform or a design framework teams adapt to their environment?
Fischer is direct on this point: Klutch is not a take-it-or-leave-it solution. It is a framework that guides teams through the design decisions they have to make, and it surfaces a reference model as anynines encounters more deployment scenarios across enterprise clients. The documentation does not yet fully reflect this direction, but Fischer describes the trajectory clearly as the framework crystallizes around real-world complexity rather than idealized topologies.
“It’s not only a solution, here it is take it or leave it. But it’s a framework that guides you through the design decisions you have to make.”
Julian Fischer, CEO, anynines
Resources & Documentation
- anynines Klutch framework, a Kubernetes platform framework providing multi-tenancy abstractions and service integrations for enterprise deployments
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: And since you mentioned tenants, I want to talk about multi tenancy and governance as well, because the fact is that developers, they want self service but without breaking all the compliance there. So can you talk about multi tenants and governance as well?
Julian Fischer: Well, what a tenant is, is to be defined by the particular way how you use your infrastructure in the first place and how you deploy kubernetes and how you use kubernetes. So we have seen scenarios where there are five kubernetes clusters for hundreds of users and application developers. I wouldn’t recommend that, but it’s what some people do and some organizations with their particular workloads can make sense of such a topology. For smaller organizations, what we see is that you have, let’s say, a production AWS account where all the applications sit together, the application clusters. But they could be, for example, isolated in different VPCs. In some other clients they are separated with networks, but not with VPCs. So that’s what I mean. You have to be flexible on the level of the a9s Hub and Klutch framework to embed and be integrated in those different scenarios. And this is where there’s just a lot of complexity that needs to be automated over time. So a tenant could mean different things in different platforms. But as a first approximation, in large enterprise clients it usually means a set of AWS accounts, where 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. So that’s what I’m saying is Klutch starts with giving you abstractions and as we see now is there will be a more or less of a blueprint where you follow a designated path defining what different types of tenants do you have? What are the services you want to integrate? Here’s a set of existing integrations or here is a way on how you write your own. So it also becomes a reference model on how to approach this problem in a more generic manner. It’s not only a solution here it is take it or leave it. But it’s a framework that guides you through the design decisions you have to make. That’s something that crystallizes right now as we see more of those different scenarios. If you go to the website right now, that’s not what you’ll find in the documentation yet, but this is where I see it evolves to.
