What is Multi-tenancy and why it Matters for Cloud Native

By Twain Taylor
November 29, 2022

Tenancy is a key concept to how organizations function in the cloud. Learn how tenancy works and how you can simplify tenancy for your organization.

Related posts

September Release - Weave GitOps 2022.09

How to Configure your Repos for Multi-Tenancy and GitOps: Zscaler’s Use Case

Weave Policy Engine is now Open Source

Tenancy is a topic that is not discussed as much as it should be, and yet, it is one of the most important parts of making cloud-native operational at scale. Every organization deals with numerous teams, projects, applications, partners, and customers. These groups of people or ideas, or objects often share a common underlying infrastructure. In doing so, they become tenants of each other. Managing these tenants is key to ensuring the success of an organization. This responsibility falls on the shoulders of the platform engineering team. In this post, we look at what tenancy is, and how platform engineers should approach tenancy as they build and support the technology infrastructure in their organizations.

What is tenancy in the cloud?

TechTarget defines tenancy as follows: “A multi-tenant cloud is a cloud computing architecture that allows customers to share computing resources in a public or private cloud. Each tenant's data is isolated and remains invisible to other tenants.”

Tenancy is all about the management of shared resources. These resources can be compute, memory, storage, or any other component of a system, and they can be shared between users, applications, projects, or even entire organizations.

The concept of tenancy was made popular with the rise of cloud computing services like AWS, which allowed multiple customers to share a single EC2 instance, for example. There was frequent talk about the noisy neighbor syndrome, which describes a “co-tenant that monopolizes bandwidth disk I/O, CPU, and other resources.”

Why is cloud tenancy important?

Unlike the traditional client-server model where each application ran on a single server, or multiple servers in parallel, today, tenancy is the modus operandi. Today, cloud resources are shared between teams, users, applications, and more.

Especially at enterprise scale, tenancy is key to enabling numerous software delivery teams to function seamlessly and efficiently on right-sized resources. Enterprises require granular control over the boundaries between tenants for their teams to operate effectively.

Benefits of cloud tenancy

Many benefits make tenancy attractive to any organization, some of which include:

  • Lower costs: By running more than one application on a single node, you can reduce the number of nodes required, and save on costs. At scale, this can add up, making tenancy a great way to reduce cloud spending.
  • Better resource utilization: With fewer resources running at any given time, there is less management overhead. This is a great way to reduce complexity by reducing the size of the system and reducing the number of things that can potentially break.
  • Reduce blast radius: In every software system, something will eventually fail. Rather than prevent failures, the best option is to be prepared for failures by isolating each tenant from its neighbor. This way, there is a clear boundary between services, users, or projects. It helps improve security as bad actors need to work harder to gain access to neighboring tenants. It also improves reliability as services can fail without taking down neighboring services.

Challenges with cloud tenancy

Despite the benefits, there are challenges when it comes to tenancy.

  • Difficult to operationalize: Tenancy is a complex process as it involves adding new tenants, defining each tenant’s permissions, preparing for failures, and more. It’s easy to get any of these wrong, and typically tenancy does go wrong in a lot of cases.
  • Security risks: One compromised tenant could affect another. With different roles assigned to users, privilege escalation can occur where bad actors attempt to gain access not allowed to them originally.
  • Noisy neighbor: Each tenant has its own set of performance metrics, SLAs and SLOs. It’s the job of the infrastructure owner to ensure these criteria are met. This is especially true when there are tenants that consume too much resources, affecting their neighbors’ performance. Putting in place checks and balances to ensure all tenants have their fair share of resources is essential to managing tenants successfully.

In today’s cloud-native world, Kubernetes is the leading orchestration tool. Its influence on cloud operations cannot be understated. No discussion of tenancy would be complete without discussing how it is handled in Kubernetes systems.

Cloud-native tenancy with Kubernetes

The Kubernetes documentation states that “ While Kubernetes does not have first-class concepts of end users or tenants, it provides several features to help manage different tenancy requirements.” Kubernetes focuses on isolating tenants at multiple levels:

  1. Control plane isolation
    1. Namespaces
    2. Role-based access controls (RBAC)
    3. Resource Quotas
  2. Data plane isolation
    1. Network isolation
    2. Storage isolation
    3. Sandboxing containers
    4. Node isolation

Among these approaches to isolation, namespaces are particularly crucial and the most common way to manage tenancy with Kubernetes. A Kubernetes namespace is a way to isolate resources within a cluster. In a Kubernetes cluster, there can be objects such as shared libraries, deployments, and services that are separated by namespaces.

The simplest form of tenancy with Kubernetes is a single cluster, single tenant setup. Beyond this, tenancy can be setup as a multi-cluster single tenant, or multi-cluster multi-tenant. In each case, the complexity keeps increasing.

Though the Kubernetes documentation mentions teams and customers as two examples of tenants, as the cloud-native model matures, there are more use cases for tenancy. Here are some ways tenancy can be used:

  • Roles
  • Role bindings
  • Namespaces
  • Teams
  • Projects
  • Applications
  • Partner organizations
  • Customers

As you can see, there are numerous use cases for tenancy, making it a key part of modern cloud-native operations. The interesting thing is that tenancy has more use cases internally, within an organization, than externally. It is a powerful tool for managing infrastructure and resources for a large developer organization.

Multi-tenancy with Weave GitOps

Weave GitOps Enterprise, our enterprise-grade GitOps solution, has recently added a new feature called Workspaces - our take on the tenancy feature described above. It is based on the core tenets of the GitOps operational model, and greatly simplifies how tenancy is managed.

Weave GitOps Workspaces empowers platform engineers to create multiple workspaces or tenant environments using one or more YAML files, and a single CLI command. Workspaces enable you to define granular policies that govern each workspace, and view and manage them all in one place in a YAML file, or in an easy-to-use UI. By enabling policy checks across build, deploy, and run-time, Workspaces ensures security guardrails are built into the software delivery process. Read the follow-up to this article to know all about Weave GitOps Workspaces.

If you are responsible for software delivery at a mid-to-large size organization, you would benefit greatly from using something as powerful as Workspaces. Download Weave GitOps today, and explore how Workspaces can revolutionize the way your organization delivers software or contact us for a demo today.

Related posts

September Release - Weave GitOps 2022.09

How to Configure your Repos for Multi-Tenancy and GitOps: Zscaler’s Use Case

Weave Policy Engine is now Open Source

Whitepaper: How GitOps Enables A Continuous Application Lifecycle

Discover what you need to start building a GitOps pipeline today.

Download now