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.

Separating one dimension does not necessarily separate the others. A workspace may restrict access while drawing compute from a shared pool. Performance isolation then depends on scheduling, reservations, and resource limits rather than folder organization. Without tenant identity in usage records, actual consumption is hard to attribute, but shared costs can still be allocated using a stated fixed or proxy-based policy.

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. Pooling tends to raise utilization and lower cost per tenant, as long as the pool does not have to be sized far above average demand to keep every tenant within its target when peaks coincide. Every separation depends on configuration being right, and a mistake in a shared component can reach every tenant that depends on it.
• 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 and separate clusters create different boundaries. An account can separate administration without dedicating compute; a cluster can separate compute while sharing storage, networks, identity, or provider services. Check access, performance, cost attribution, and change impact individually. Policies may be centrally inherited or distributed, depending on the platform.
• 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