Multitenancy refers to a principle in software architecture where a single instance of the software runs on a server, serving multiple client organizations (tenants). Multitenancy is contrasted with a multi-instance architecture where separate software instances (or hardware systems) are set up for different client organizations. With a multitenant architecture, a software application is designed to virtually partition its data and configuration, and each client organization works with a customized virtual application instance.
Multitenancy is also regarded as one of the essential attributes of Cloud Computing.[1]
The principle of multitenancy is not universally accepted and supported within the software industry, and this may be a source of competitive differentiation (see below).
Contents |
Multitenant applications have evolved from—and combine some characteristics of—three types of services:
In a multitenancy environment, multiple customers share the same application, running on the same operating system, on the same hardware, with the same data-storage mechanism. The distinction between the customers is achieved during application design, thus customers do not share or see each other's data. Compare this with virtualization where components are abstracted enabling each customer application to appear to run on a separate physical machine.[2]
Some companies actively promote the principle of multitenancy and use it as a source of competitive differentiation.[3][4]
Multitenancy allows for cost savings over and above the basic economies of scale achievable from consolidating IT resources into a single operation.[5] An application instance usually incurs a certain amount of memory and processing overhead which can be substantial when multiplied by many customers, especially if the customers are small. Multitenancy reduces this overhead by amortizing it over many customers. Further cost savings may come from licensing costs of the underlying software (such as operating systems and database management systems). Put crudely, if you can run everything on a single software instance, you only have to buy one software license. The cost savings can be eclipsed by the difficulty of scaling the single instance (a bigger, faster server can only take one so far) as demand grows. In addition, development of multitenant systems is more complex, and security testing is more stringent.
One of the most compelling reasons for vendors/ISVs to utilize multitenancy is for the inherent data aggregation benefits. Instead of collecting data from multiple data sources, with potentially different database schemas, all data for all customers is stored in a single database schema. Thus, running queries across customers, mining data, and looking for trends is much simpler. This reason is probably overhyped as one of the core multitenancy requirements is the need to prevent Service Provider access to customer (tenant) information. Further, it is common to separate the operational database from the mining database (usually because of different workload characteristics), thus weakening the argument even more.
Because of the additional customization complexity and the need to maintain per-tenant metadata, multitenant applications require a larger development effort.
Multitenancy simplifies the release management process. In a traditional release management process, packages containing code and database changes are distributed to client desktop and/or server machines. These packages then have to be installed on each individual machine. With the multitenant model, the package typically only needs to be installed on a single server. This greatly simplifies the release management process.
At the same time, multitenancy increases the risk of applying a new release version and the effects of that. As there is a single software instance serving multiple tenants, an update on this instance may cause downtime for all tenants even if the update is requested and useful for only one tenant. Also, some bugs and issues resulted from applying the new release could manifest in other tenants' personalized view of the application. Because of possible downtime, the moment of applying the release may be restricted depending on time usage schedule of more than one tenant.
Multitenant applications are typically required to provide a high degree of customization to support each target organization's needs. Customization typically includes the following aspects:
Multitenant applications are expected to provide adequate levels of security and robustness, which are provided by the operating system in the case of multi-instance applications.
The costs of re-designing applications for multitenancy can be significant, especially for software vendors who continue to offer an on-premises single tenant version of their product. They end up being forced to support two distinct products with all the resulting costs.
An increasingly viable alternative route to multitenancy that eliminates the need for significant architectural change is to use virtualization technology to host multiple isolated instances of an application on one or more servers. Indeed, when applications are repackaged as virtual appliances the same appliance image can be deployed in ISV hosted, on-premises or trusted-third party locations and even migrated from one deployment site to another over time.