What is multi-tenancy (multi-tenant architecture)?

Why is multi-tenancy important?

Multi-tenancy is an old idea and traces its roots to classical mainframe architectures where many apps and users shared a common computing hardware platform. With the reintroduction and broad adoption of modern hardware-assisted virtualization, the ability to share hardware among multiple software instances -- such as virtual machines (VMs) and their applications -- placed a new emphasis on multi-tenancy capabilities. The technique gained popularity across local data centers and within hosted infrastructures normally associated with colocation and other shared IT services -- all enabling many users to share limited or common hardware infrastructure.

More recently, multi-tenancy has seen its most dramatic adoption with cloud computing. Multi-tenant architectures are found in both public cloud and private cloud environments, enabling each tenant's data to be separated from other tenants. For example, in a multi-tenant public cloud, the same servers will be used in a hosted environment to host multiple users. Each user is given a separate and ideally secure logical space within those servers to run applications and store data.

Multi-tenancy is also important for the scalability of public and private clouds and has helped make multi-tenancy a standard. The multi-tenant architecture can also help provide a better ROI for organizations, as well as accelerate the pace of maintenance and updates for tenants.

Types of multi-tenant architecture

There are three main multi-tenancy model types, all with varying levels of complexity and costs. Each model is traditionally discussed in terms of application and database -- the data used by the application -- relationships.

1. Single application, single database

 A single, shared database schema is a multi-tenancy model with a multi-tenant database. This is the simplest form out of the three model types and has a relatively low cost for tenants because of the use of shared resources. This form uses a single application and database instance to host multiple simultaneous tenants and store data. Using a single, shared database schema enables easier scaling; however, operational costs can be higher and noisy neighbor effects can potentially affect performance.

2. Single application, multiple database

This multi-tenant architecture includes the use of a single database with multiple schemas. This tenant system uses a single application instance with individual databases for each tenant. In addition, this architecture is more difficult to scale and has a higher cost and more overhead with each database. It's a valuable architecture when data from different tenants need to be treated differently -- such as if they had to go through different regulations per geographic region. Separate databases also help to reduce potential noisy neighbor effects.

3. Multiple application, multiple database

This type of multi-tenant architecture hosts data in multiple databases. This model is relatively complex in terms of cost, management and maintenance, but the approach is secure and tenants can be separated by a chosen criterion.

Advantages and disadvantages of multi-tenancy

There are a number of advantages and disadvantages that come with becoming a host provider and a tenant with multi-tenancy. Some advantages include the following:

• It's less expensive compared to other tenant hosting architectures.
• It offers pay-for-what-you-use and pay-as-you-go (PAYG) pricing models.
• Tenants that use a provider's software don't have to worry about updates, because they're pushed out by the host provider.
• Tenants don't have to worry about the hardware their data is being hosted on.
• Providers only have to monitor and administrate a single system.
• The architecture is easily scalable.

Some disadvantages that come with multi-tenancy include the following:

• Apps delivered by a provider tend to be less flexible than apps in other tenant architectures, such as single-tenancy.
• It is, in general, more complex than single-tenancy because of the additional virtualization and management needed to isolate and secure each tenant.
• Apps need stricter authentication and access controls for security.
• Tenants have to worry about noisy neighbors, which might slow response time for other tenants sharing the same resources.
• Downtime might also be an issue, depending on the provider. Collateral impacts such as one server problem affecting many users can also be an undesirable risk.

Multi-tenancy examples

There are numerous examples of multi-tenancy, including the following:

Hardware -- VM and container -- multi-tenancy

 Hardware virtualization enables multiple VMs and virtual containers to be created and hosted on a common server with each VM running a separate application or service managed by a different stakeholder, department or customer. Hardware multi-tenancy is widely used in modern data centers and colocation environments and is a fundamental enabler for all cloud computing.

Public cloud multi-tenancy

 Customers use instances of resources and services to assemble an infrastructure that's appropriate for hosting a business application. But every cloud resource or service shares underlying hardware and network bandwidth. Public clouds can deliver dedicated resources to customers, but this is an exception rather than the rule.

Private cloud multi-tenancy

A private cloud shares the same multi-tenancy concepts as a public cloud, but a private cloud is dedicated to a single organization or group, whereas a public cloud serves the interests of many customers or groups.

SaaS multi-tenancy

This is a variation of public cloud multi-tenancy because software as a service (SaaS) providers are generally classified as cloud providers. A SaaS provider, for example, can run one instance of its application on one instance of a database and provide web access to multiple customers. In such a scenario, each tenant's data is isolated and remains invisible to other tenants. Multi-tenancy can also be implemented in multi-tier systems such as an SAP system.

Serverless multi-tenancy

 Serverless computing provides a cloud service that uses events to load and run a customer's code and then dismisses that infrastructure when the code is executed. Many applications can share the same function, and the function loads and runs on any available shared hardware infrastructure.

Multi-tenant vs. single-tenant

Multi-tenancy can be contrasted with single-tenancy, an architecture in which each customer has its own software instance and may be given access to source code.

A single-tenant architecture resembles a one-server-one-application approach that's reminiscent of traditional data centers before the broad adoption of server virtualization. In hosted single-tenant architectures, a tenant will have a singular instance of a SaaS application dedicated to them, unlike multi-tenancy where there are shared services. Because each tenant is in a separate physical environment or infrastructure, they aren't bound in the same way that users of shared infrastructure would be -- meaning single-tenant architectures are much more customizable.

Multi-tenancy is used more often, as most local data centers, SaaS and other cloud services operate on multi-tenancy. In comparison to single-tenancy, multi-tenancy is cheaper, has more efficient resource usage and fewer maintenance costs, as well as the potential for larger computing capacity. With a multi-tenant architecture, the provider only has to make updates once. With a single-tenant architecture, the provider must touch multiple instances of the software in order to make updates.

A potential customer would likely choose a single-tenant infrastructure over multi-tenancy for the ability to have more control and flexibility in their environment -- typically to address specific requirements such as security or regulatory compliance.

Learn how data separation strategies in cloud computing can help organizations keep data safe and ensure that business goals are being met.