Multi-Tenancy

Multi-tenancy is an arrangement in which one system serves several tenants — customers, business units, or teams — using shared resources, while keeping each tenant’s view, data, and experience appropriately separate. The opposite arrangement, single tenancy, gives each tenant its own dedicated copy of the system.

The reason to share is economic. Microsoft’s architecture guidance puts it plainly: sharing some or all resources between tenants brings cost and operational efficiency, and it also brings complexity. Almost every decision about multi-tenancy is a decision about where to draw that line.

What a tenant is

There is no universal definition, and the Kubernetes documentation says so directly. It describes two broad patterns. In multi-team tenancy, teams inside one organization share a cluster; they usually have some trust in each other and direct access to the platform. In multi-customer tenancy, a vendor runs workloads for separate customers who never see the underlying platform and may not trust each other at all. Many organizations use both definitions in different places.

A data platform serving an enterprise is usually the first kind stretched toward the second: business units and subsidiaries with separate budgets, separate confidentiality rules, and sometimes external partners.

What has to be separated

“Isolated” is not one property. At least four things can be shared or separated independently, and a design can be strong on one and weak on another.

The common mistake is to assume that separating one dimension separates the others. A separate workspace or project per tenant usually separates access and ownership, but whether it separates performance depends on whether each workspace draws from its own compute. If two tenants run in the same pool, they share a queue however their folders are organized — and the same is true of cost, which cannot be split afterwards from a pool that recorded no tenant identity.

Isolation is a spectrum

Isolation is often described as “hard” or “soft,” and the Kubernetes documentation cautions that these labels are better understood as a spectrum than as two settings. At one end, everything is shared and separation is enforced in software. At the other, each tenant gets dedicated infrastructure. The documentation notes that the benefit of stronger isolation has to be weighed against the cost and complexity of running many separate environments, and that isolation applies to the control plane as well as to where workloads run.

• Fully shared. Highest utilization and lowest cost per tenant. Every separation depends on configuration being right, and a mistake in shared components reaches everyone.
• Shared control, separate compute. One platform with per-tenant compute pools and access rules. Performance and cost can be separated while governance stays central.
• Dedicated per tenant. Separate accounts or clusters. Strong on all four dimensions, but sharing data between tenants becomes a project, and central policies must be replicated everywhere.
• Hybrid. Shared by default, dedicated for tenants with a specific reason: a residency obligation, a stricter availability target, or load that harms others.

For the hybrid model, the valuable artifact is the rule that decides placement, written down. Without it, tenants gain dedicated infrastructure through escalation rather than need, and a shared platform gradually turns back into many small ones.

How these choices play out when business intelligence, data science, and operational services share one data platform is worked through in Enterprise Scale: One Platform, Workloads That Disagree.

References: Kubernetes Documentation, Multi-tenancy; Azure Architecture Center, Architectural considerations for a multitenant solution.