Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers. Each customer is called a tenant. Tenants may be given the ability to customize some parts of the application, such as the color of the user interface (UI) or business rules, but they cannot customize the application’s code.

Multi-tenancy can be economical because software development and maintenance costs are shared. It can be contrasted with single-tenancy, an architecture in which each customer has their own software instance and may be given access to the code. With a multi-tenancy architecture, the provider only has to make updates once. With a single-tenancy architecture, the provider has to touch multiple instances of the software in order to make updates.

In cloud computing, the meaning of multi-tenancy architecture has broadened because of new service models that take advantage of virtualization and remote access. A software-as-a-service (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.

Whether an IT organization is going with public or private clouds, it’s important to understand the nuances of multi-tenant architecture. For public clouds, IT managers need to understand the degree of multi-tenancy supported by whichever vendor they are looking at. For private clouds, the entire responsibility of designing a multi-tenant architecture rests with the IT managers.

Enterprise cloud adoption has gone beyond the levels of intellectual pursuits and casual experimentation. An analysis by IDC shows that $17 billion of the $359 billion of worldwide IT spending for 2009 could be attributed to cloud computing. Two-thirds of Baseline magazine’s survey participants plan to expand their use of public clouds.

None of that is to say that there aren’t nagging issues, including but not limited to how different enterprise workloads match up against different types of clouds and responsible ways to plan and implement the necessary migrations.

Based on the characteristics of the workload, cloud adoption will swing between public and private clouds. Large enterprises have requirements that will force them to strike a balance between the two clouds for their workloads. This is different for small-to-medium businesses (SMBs) and start-ups, which might have a strong business case for wanting to use public clouds for almost all of their workloads. But in the end, their respective preferences will not be as much about the size of the organization as they are about the nature of their IT workloads.

Besides appropriate workload distribution, architectural considerations are also key. Multi-tenancy is one such architectural consideration, and understanding multi-tenancy is a critical first step towards broader IT cloud adoption.

Due to the early traction is seen in public clouds — where multiple enterprises end up being co-tenants — “multi-tenancy” is wrongly used as a synonym for “multi-enterprise.” But they are very different concepts. Also, the granularity of tenancy is established at the application level, not at the level of an individual user or entire enterprise.

Multi-tenancy defined

A tenant is any application — either inside or outside the enterprise — that needs its own secure and exclusive virtual computing environment. This environment can encompass all or some select layers of enterprise architecture, from storage to user interface. All interactive applications (or tenants) have to be multi-user in nature.

A departmental application that processes sensitive financial data within the private cloud of an enterprise is as much a “tenant” as a global marketing application that publishes product catalogs on a public cloud. They both have the same tenancy requirements, regardless of the fact that one has internal co-tenants and the other has external.

Multi-tenancy is the key common attribute of both public and private clouds, and it applies to all three layers of a cloud: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS).

Most people point to the IaaS layer alone when they talk about clouds. Even so, architecturally, both public and private IaaSes go beyond tactical features such as virtualization and head towards implementing the concept of IT-as-a-Service (ITaaS) through billing — or chargeback in the case of private clouds — based on metered usage. An IaaS also features improved accountability using service-level-agreements (SLAs), identity management for secured access, fault tolerance, disaster recovery, dynamic procurement and other key properties.

By incorporating these shared services at the infrastructure layer, all clouds automatically become multi-tenant, to a degree. But multi-tenancy in clouds has to go beyond the IaaS layer, to include the PaaS layer (application servers, Java Virtual Machines, etc.) and ultimately to the SaaS or application layer (database, business logic, workflow and user interface). Only then can tenants can enjoy the full spectrum of common services from a cloud — starting at the hardware layer and going all the way up to the user-interface layer, depending on the degree of multi-tenancy offered by the cloud.

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, the 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 (or schema) 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.

For example, Salesforce.com, at the relatively high end of the multi-tenancy spectrum, has 72,500 customers who are supported by 8 to 12 multi-tenant instances (meaning IaaS/PaaS instances) in a 1:5000 ratio. In other words, each multi-tenant instance supports 5,000 tenants who share the same database schema. Intacct, a financial systems SaaS provider in the middle of the spectrum, has more than 2,500 customers who share 10 instances in a 1:250 ratio.

Private clouds, and offerings such as SAP‘s Business By Design (due this summer), would be at the lowest end of the spectrum of multi-tenancy, with application layers that are dedicated and are more suited for specific large enterprise customers.

How to choose your multi-tenancy degree

One size doesn’t fit all when choosing between different degrees of multi-tenancy. The characteristics of the workload in question have to be carefully studied first, including the workload’s utilitarian versus strategic value, volatility, security, etc. Higher degrees of multi-tenancy is best suited for cross-industry utilitarian workloads such as catalog management and sales force management.

These applications can very easily share the same schema and also benefit from a rapidly evolving set of features that are best developed centrally by a vendor or a corporate shared services team. They also tend to have simpler security requirements such as encryption and authorization. That’s why public clouds are attractive multi-tenant platforms for “low-hanging fruit” types of workloads such as e-mail, collaboration, situational applications (expense reporting, travel authorization) and pre-production activities (development, user training, and functional/acceptance testing).

For each such workload, IT managers need to determine the degree of multi-tenancy needed and accordingly choose their providers from a growing list of vendors.

But for workloads that are meant for private and community (consortium of enterprises) clouds, the responsibility of designing a multi-tenant architecture rests with the IT managers. For these workloads, there is a large list of fast-maturing technologies from both established and start-up vendors. IT managers have to evaluate these vendors and build their own custom IaaS, PaaS and SaaS layers, including support for building shared services and shared database schema.

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 (not users) 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

Source: What is multi-tenancy? – Definition from WhatIs.com

Source: Multi-tenancy in the cloud: Why it matters | Computerworld