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.