Multi-Tenant Database Architecture
Software as a Service (SaaS) denotes a novel and innovative paradigm, and the fact that companies do not have to purchase and maintain their own Information Technology (ICT) infrastructure; instead services from third party are acquired. Multi-tenancy permits SaaS providers to provide similar service to various customers (tenants), which share physical and/or virtual resources transparently.
Multi-tenancy database architecture essentially forms a design in which a single instance of the software is run on the service provider’s infrastructure, and multiple tenants access the same instance. Simply put “A multi-tenant application lets customers (tenants) share the same hardware resources, by offering them one shared application and database Instance, while allowing them to configure the application to fit their needs as if it runs on a dedicated environment”.
One of the most conspicuous features of Multi-tenant architecture is that allows for consolidating multiple businesses onto the same operational platform or system. Multi-tenancy invariably takes place at the database layer of a service. As an analogy, think of a rental apartment building with numerous tenants, each having its own requirement of storage, space, and utilities.
Easier application deployment for Service Providers, improved rate of hardware utilization, and reduction in overall costs especially for SMEs are core benefits of Multi-tenant model.
Multi-tenancy was in fact pioneered by salesforce.com. In traditional single-tenant software development, tenants usually have their own virtual server. This set-up is similar to the traditional Application Service Provider (ASP) model. However, in the SME segment, for instance, server utilization in such a model is low. By placing several tenants on the same server, the server utilization can be improved.
There are three different kinds of Multi-tenant models that exist in database applications today are as follows:
- Separate application, separate database, and infrastructure (Isolated Tenancy)
- Separate application, separate database, shared infrastructure (Infrastructure Tenancy)
- Shared application separate database, shared infrastructure (Application Tenancy)
Shared application, shared database, shared infrastructure (Shared Tenancy) is perhaps the ‘purest’ form of Multi-tenancy environment. The above figure illustrates various Multi-tenant approaches as a continuum paradigm. The far left (Isolated Tenancy) depicts each tenant with its own application instance running and as we move further towards the right, sharing of tenancy increases, ultimately reaching the far right side (Shared Tenancy).
From the functionality point of view, the multi-tenant system have limited modifications to the software, because multiple customers are running the same instance of the software and their data is being placed in a pre-configured database format. Multi-tenant SaaS providers generally do a very good job of anticipating the needs of current and prospective customers and the standardized functionality that is often needed by a company.
Due to the low number of instances, multi-tenancy sounds like a maintenance dream. Deployment of software updates becomes much easier and cheaper, due to the fact that a much smaller number of instances has to be updated. However, the complexity of the code does increase, that may possibly lead to maintenance issues. As cloud computing technology continues to grow and mature, further research related to reviewing real world cloud implementations, challenges, benefits, and lessons learned will benefit organizations that are currently considering or planning a SaaS based implementation.
By Syed Raza
