Implementing a Multi-Tenancy Architecture, Tier by Tier

Implementing a Multi-Tenancy Architecture, Tier by Tier

A typical software stack consists of two tiers (an application tier and a database tier) and three layers (the application layer, the middleware layer and the infrastructure layer). In this second installment of my implementing a multi-tenant cloud architecture series, I go step by step through the application layers and tiers, exploring the options for implementing multi-tenancy on each. The first installment explored the common strategies for implementing a multi-tenant architecture.

Multi-Tenancy for All Layers of the Application Tier

I begin with the multi-tenancy options for the three layers of the application tier. Figure 1 below provides a reference for our discussion, where T refers to tier, MW refers to middleware, and VT refers to virtualized tenant.

Multi-tenant cloud architecture
Figure 1. Multi-Tenancy for Application Layer of the Application Tier

Multi-Tenancy for the Application Layer

Here are the multi-tenancy options at each application layer:

  1. Enable a complete multi-tenancy application that serves multiple tenants, T1 to T3. The application itself resides on MW. This is a typical consideration for applications and services that are either built from scratch or re-engineered. In such a scenario, the application has all the capabilities required to serve multiple tenants at the same time.
  2. Enable multi-tenancy with virtualized tenants through a smart feature of the underlying MW1. If the application is not enabled with multi-tenancy, but the MW has capabilities to deploy it virtually in a multi-tenancy fashion, this might provide the application multi-tenancy capabilities.
  3. Instantiate an application instance and a corresponding MW instance per tenant. This might not be the only option if neither the application nor the capabilities in the MW allow multi-tenancy, as in options 1 and 2. In this case, multi-tenancy capabilities can be achieved on only the MW layer or the infrastructure layer.

Multi-Tenancy for the Middleware Layer

Each MW instance requires its own OS environment (see Figure 3 below). The OS is capable of serving multiple instances of the MW, which requires process-level and address space-level separation capabilities. The OS has virtualized OS capabilities with the instances vOS1 to vOS3. Each MW runs on its own virtualized OS environment.

Multi-tenant cloud architecture
Figure 2. Multi-Tenancy for Middleware Layer of the Application Tier

Multi-Tenancy for the Infrastructure Layer

For infrastructure layer, you have only two options:

  1. A single OS instance per hardware instance
  2. Multiple OS instances (OS1 to OS3) per hardware instance

Multi-Tenancy for the Data Tier

Historically, each application had its own database system in the data tier. The downside of this approach is it spawned multiple hardware instances, each with its own OS, in addition to multiple database environments that need to be individually installed, configured, monitored and managed over time. Each installation of the database software created redundancy in the installed software, wasting disk space.

With the rise of the schema concepts to group tables and other database objects, schemas can be used to separate information logically for one application from information belonging to another application.

The concept of schemas offers the following multi-tenancy options:

  • A fully multi-tenancy enabled application that is self-sufficient within one schema. This choice is often available only for new applications and services or reengineered applications. There is no logical separation for the multiple tenants sharing the single application instance. Thus, backup or restore operations per tenant are difficult.
  • One schema per tenant. In this case, there is still just one application instance shared by multiple tenants, but the information is logically separated in the database with one schema per tenant. This is a precondition for something known as schema-based database operations. Some commercial databases allow maintenance services on a schema level. Thus, when designing for or selecting this option, one must check for these capabilities during the software selection step of the operation model design process.
  • If the application is not multi-tenancy enabled, the MW layer below the schema layer — in the data tier given by the database — must provide multi-tenancy. This typically means a one-to-one relationship between application instance and schema and between schema and database. The benefit of this approach is that this configuration is well supported by database vendors today with maintenance operations on a database level.

Figure 4 shows the multi-tenancy options for the schema layer of the data tier.

Multi-tenant cloud architecture
Figure 3. Multi-Tenancy for Schema Layer of the Data Tier

Multi-Tenancy for Middleware Layer in Data Tier

The MW layer (database server) for the data tier has exactly the same conceptual choices as for the application tier. The difference is that in the application tier, the MW layer is applicable for the application servers, whereas in the data tier the MW is typically databases or content management systems.

A couple of MW multi-tenancy options exist for the data tier:

  • The OS is able to serve multiple instances of the database systems. This requires process-level and address space-level separation capabilities.
  • The OS has virtualized OS capabilities. In this example, each database instances runs in its own virtualized OS environment using technologies such as XEN or VMware as providers of virtualized OS environments. For example, this can be an efficient mechanism for providing various departments with database systems dedicated to testing.

Proper Planning Is Critical

There are multiple ways to implement multi-tenancy. Which one you choose depends on the nature of the service being implemented. Whichever approach you choose, you must spend the necessary time upfront during the architecture phase to determine your current and future multi-tenancy needs and to come up with the best design for supporting multi-tenancy. After your chosen approach has been implemented, it can be extremely difficult and costly to change, much like converting a four-unit apartment complex into a multiplex would be almost impossible without starting from scratch.

Share the Post:
XDR solutions

The Benefits of Using XDR Solutions

Cybercriminals constantly adapt their strategies, developing newer, more powerful, and intelligent ways to attack your network. Since security professionals must innovate as well, more conventional endpoint detection solutions have evolved

AI is revolutionizing fraud detection

How AI is Revolutionizing Fraud Detection

Artificial intelligence – commonly known as AI – means a form of technology with multiple uses. As a result, it has become extremely valuable to a number of businesses across

AI innovation

Companies Leading AI Innovation in 2023

Artificial intelligence (AI) has been transforming industries and revolutionizing business operations. AI’s potential to enhance efficiency and productivity has become crucial to many businesses. As we move into 2023, several

data fivetran pricing

Fivetran Pricing Explained

One of the biggest trends of the 21st century is the massive surge in analytics. Analytics is the process of utilizing data to drive future decision-making. With so much of

kubernetes logging

Kubernetes Logging: What You Need to Know

Kubernetes from Google is one of the most popular open-source and free container management solutions made to make managing and deploying applications easier. It has a solid architecture that makes

ransomware cyber attack

Why Is Ransomware Such a Major Threat?

One of the most significant cyber threats faced by modern organizations is a ransomware attack. Ransomware attacks have grown in both sophistication and frequency over the past few years, forcing

data dictionary

Tools You Need to Make a Data Dictionary

Data dictionaries are crucial for organizations of all sizes that deal with large amounts of data. they are centralized repositories of all the data in organizations, including metadata such as