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.

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.

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.

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.