Multi tenant Database Application Platform

1. Isolated Tenancy (Shared Nothing)

   Under this concept, each tenant has its own dedicated stack of underlying technology; nothing is shared. This is not true multitenancy, although users may experience it as multitenancy, because the same application is offered from the same external data center to many user organizations as a service.

2. Multitenancy via Shared Hardware (Elastic Virtualization)

   Under this concept, each tenant has its own dedicated stack of technology, but the (virtual) machines are allocated from a pool of shared hardware using an elasticity layer over some form of hypervisor-based virtualization (the virtual machine is the typical technology approach, although sharing of the operating system, is also possible). This model shares many characteristics of isolated tenancy, because most of the stack underlying the application is dedicated to a tenant — but it can be true multitenancy, as long as the underlying machine resources are shared in an elastic manner among the tenants.

3. Multitenancy via Shared Process

   Under this concept, multiple tenants' transactions are executed in the same instance of an application container (specialized application server, a SEAP), but each tenant is associated with a separate logical or physical instance of the DBMS. Thus, the execution environment is shared among tenants, but the data platform is not. The premise of this approach is that DBMS isolation would ensure the integrity of tenants' data, while the shared application execution container offers advanced fine-grained elasticity and customization opportunities.

4. Multitenancy via Shared Everything

   This model is an enhanced variant of the SEAP-based multitenancy model discussed above. The SEAP model is still the center of action; however, here the application execution platform and the data platform are both shared by multiple tenants — under the management control of SEAP. This model shares the benefits and costs of the SEAP-based multitenancy model, and adds precision in managing shared resources at the cost of eliminating the possibility of physically isolated management of tenants' data. The providers typically use a third-party DBMS, but they allocate only a single logical instance for all tenants, and manage tenant data isolation in the SEAP.

5. Multitenancy via Custom Application Design

   Some SaaS-style applications have been designed using conventional programming languages over conventional third-party platforms, yet are offered as a multitenant service. Typically, such applications implement the principles of multitenant isolation as part of the application code itself.

A multi-tenant Cloud architecture permits a vendor to service its customer base effectively using shared operational instances of the infrastructure. In addition to significantly lowering service delivery cost as well as operational expenses and efforts, this model brings several benefits to the customer. The obvious benefit is the lower TCO for customers. With optimal utilization of its infrastructure, the vendor can deliver higher value at lower cost. Applying the economies of scale, a growth in the customer base would enable the vendor to offer further benefits.

An important feature of this model is that it affords portability and helps minimize risk for customers. By maintaining identical instances, the vendor can easily shift a customer, in case of unexpected failure or growth, from one instance to another without the need for major architectural changes. Eliminating the need to maintain individual instances (code bases, infrastructure, etc.) for customers equates to frequent upgrades and easier maintenance.

Single tenant versus Multi tenant architecture

In single tenant architecture an application is dedicated to a single customer or tenant. The data is stored in separate servers and managed by hosting provider. Each tenant runs its dedicated copy of the application. The separation of the data can be either virtual or physical. The level of security is very high as there is no scope of data migration. The application can be customized to meet the specific and special needs of each customer. From the way the UI looks to the way database is maintained, everything can be customized.

In Multi tenant architecture, the data from multiple companies are placed on the same server generally separated from each other via a simple partition that prevents data to migrate from one company to another. As the data is housed on the same server, each company using the software is running the same basic application, with the same basic functionality and with the same limited configuration capabilities. The customizations to the application are limited because multiple customers use the same instance of application.

Degrees of multi-tenancy

The exact degree of multi-tenancy, as it's commonly defined, is based on how much of the core application, or SaaS, layer is designed to be shared across tenants. The highest degree of multi-tenancy allows the database schema to be shared and supports customization of the business logic, workflow and user-interface layers. In other words, all the sub-layers of SaaS offer multi-tenancy in this degree. In the lowest degree, multi-tenancy is limited to the IaaS and PaaS layers, with dedicated SaaS layers for each tenant. And in the middle degree of multi-tenancy are clusters of homogenous tenants that share database schemas and other application layers. In the middle level, each cluster of users has its own version of database schema and the application itself.

We can sum up the discussion on the degree of multi-tenancy as follows:

• Highest degree: IaaS and PaaS are multi-tenant. SaaS is fully multi-tenant also.
• Middle degree: IaaS and PaaS are multi-tenant. Small SaaS clusters are multi-tenant.
• Lowest degree: IaaS and PaaS are multi-tenant. SaaS is single tenant.

Multi-tenancy is the core tenet of cloud computing. While multi-tenancy takes forward some of the concepts of mainframe computing to the x86 server ecosystems, its ongoing efforts to scale up these mainframe concepts to support thousands of intra- and inter-enterprise tenants are complex, commendable and quite revolutionary. It's only when the required degree of multi-tenancy is incorporated into all the layers of public and private clouds that the promises of improved scalability, agility and economies of scale can be fully delivered.