Multitenancy is a software architecture where a single software instance can serve multiple, distinct user groups. Software-as-a-service (SaaS) offerings are an example of multitenant architecture.
In cloud computing, multitenancy can also refer to shared hosting, in which server resources are divided among different customers.
Multitenancy is the opposite of single tenancy, when a software instance or computer system has 1 end user or group of users.
Multitenant applications typically include a level of customization for tenants, such as customizing the look and feel of the application or allowing the tenant to decide on specific access control permissions and restrictions for users.
The idea of multitenancy has been around for decades. In the 1960s, universities with powerful, expensive mainframes developed timesharing software that allowed multiple users to access the computer at essentially the same time.
That idea never really went away, and today the concept of multitenancy is what makes cloud computing possible. A public cloud takes a pool of shared resources—processing power and memory—and divides it among multiple tenants. Each tenant's data and workloads remain isolated, even if they happen to run on the same physical machine or group of machines.
If we take the same idea a step further and apply it to software architecture, we arrive at the modern concept of SaaS. A SaaS provider runs a single instance of an application and offers access to individual customers. Each user’s data remains isolated, even though they’re accessing the same software as every other user.
When referring to a container orchestration platform such as Kubernetes, the term multitenancy usually means a single cluster that serves multiple projects. The cluster is configured so each project runs isolated from the others.
As shown previously, multitenancy as a concept is an important feature of cloud computing because it is a single instance of a software application that is provided to multiple tenants. Clouds are considered Platforms-as-a-Service (PaaS), as opposed to multitenancy, which is often associated with SaaS applications.
Cloud service providers supply users with the platform and underlying IT infrastructure that is needed for cloud computing from a pool of resources that are then allocated to multiple users (or tenants).
Cloud architecture is how all the components and capabilities necessary to build a cloud are connected in order to deliver an online platform on which applications can run.
Architecting a cloud platform requires additional levels of development to incorporate containerization, orchestration, application programming interfaces (APIs), routing, security, management, and automation software.
Public cloud architecture: A cloud environment created from resources not owned by the end user that can be redistributed to other tenants.
Private cloud architecture: Loosely defined as a cloud environment solely dedicated to the end user, usually within the user’s firewall and sometimes on premise.
Multitenancy has a whole array of advantages, which are evident in the popularity of cloud computing.
Multitenancy can save money. Computing is cheaper at scale, and multitenancy allows resources to be consolidated and allocated efficiently, ultimately saving operational costs. For an individual user, paying for access to a cloud service or a SaaS application is often more cost-effective than running single-tenant hardware and software.
Multitenancy enables flexibility. If you’ve invested in your own hardware and software, it might reach capacity during times of high demand or sit idle during times of slow demand. A multitentant cloud, on the other hand, can allocate a pool of resources to the users who need it, as their needs scale up and down. As a customer of a public cloud provider, you can access extra capacity when you need it, and not pay for it when you don’t.
Multitenancy can be more efficient. Multitenancy reduces the need for individual users to manage infrastructure and handle updates and maintenance. Individual tenants can rely on a central cloud provider, rather than their own teams, to handle those routine chores.
There's a lot more to do with clouds.
Despite the advantages of multitenancy, there are use cases that are better suited for single-tenant computer systems, such as a private cloud or using your own data center.
Chief among them: Data security for applications involving highly sensitive data. Public cloud environments and SaaS products are designed to isolate workloads and data, and have a strong record of working as designed. But in controlled tests, researchers have discovered vulnerabilities that could, at least theoretically, allow cross-tenant attacks in cloud environments.
In practice these risks are relatively small. Shared tenancy vulnerabilities are rare and require high levels of sophistication, according to a 2020 report on cloud vulnerabilities from the U.S. National Security Agency. As of the NSA’s report, there had been no documented cross-tenant attacks on any major public cloud provider. The NSA considers these risks smaller than the risks from poor access control and misconfigurations.
With VMs, a hypervisor spins up guest machines that each have their own operating system as well as applications and dependencies. The hypervisor also makes sure users are isolated from each other.
Compared to VMs, containers offer a more lightweight, flexible, and easier-to-scale model. Containers simplify multi-tenancy deployments by deploying multiple applications on a single host, using the kernel and the container runtime to spin up each container. In contrast to VMs, which each include its own kernel, applications running in containers share a kernel, even across multiple tenants.
In Linux®, namespaces make it possible for several containers to use the same resource at the same time without creating a conflict. Securing a container is the same as securing any running process.
When using Kubernetes for container orchestration, it’s possible to set up multitenant environments using a single Kubernetes cluster. It’s possible to separate tenants into their own namespaces, and create policies that enforce tenant isolation.