Introduction to Multi Tenancy in Cloud
Multi Tenancy offers customers , organizations and consumers which are sharing infrastructure and databases to gain advantages on price and performance front. Service offerings available through cloud involve customers (or ‘tenants’) getting a piece of cloud which contains the resources required to run their businesses.
Tenants may share hardware on which their virtual machines or servers run, or they may share database tables where data is stored for multiple tenants. However, security measures are mandatory to ensure tenants don’t pose risk to each other in terms of data loss, misuse, or privacy violations.
In cloud services be it SaaS, LaaS, PaaS services offered by providers. A tenant is a person who occupies land or property by giving rent. In a Multi-tenancy architecture, there are multiple occupants and tenants who share software, but each consumer is unaware of the other tenant. It allows one instance of an application to serve multiple customers by resource sharing. Independent customers are serviced. The security of data is of prime concern as data is the key factor between customer and provider. The data architecture in a multi-tenancy model should be robust, secure, efficient, and cost effective.
Impact of Multi tenancy
Master data support – master data is shared instead of replicating for every tenant for cost reduction. Data is shared across organizations and may be modified by tenants as per their requirement and DBMS should support those changes privately to each tenant’s needs.
Application modifications and extensions – applies to database schema and its master data . This is required to tailor application to tenant specific requirements. Limited form of customization or ability to modify database schema of the application or building an extension to be sold as an add-on to base application as per tenant business need.
Schema evolution and master data – when applications are upgraded , offered as self-service to contain operational costs, and require minimal amount of interaction between service provider and tenants.
Approaches of Multi Tenancy in Cloud
There are three approaches to manage Multi-tenant data as under : –
- Separate database process, shared system
- Shared database process, separate tables
- Shared tables
1. Separate database process, shared system
The system is shared, and each tenant gets its own database process. Computing resources and application code are shared among all tenants on a server, each tenant has its own set of data which remains logically isolated from other tenant’s data.
Separate database process, shared system: Pros and Cons
- Easy to implement
- Can be customized for each customer and vendor can apply new releases or customization as per customer requirement
- Heavy on resources
- Every customer has unique configuration and vendor need to manage them all
- Expensive in terms of management, integration, updates, customer support etc
2. Shared database process, separate tables
Every tenant has its own table and multiple tenants share the same database process. Multiple tenants are housed in the same database, each tenant having its own table which are grouped into a schema specific to a tenant.
Shared database process, separate tables: Pros and Cons
- Low licensing costs
- Low cost of maintenance
- Less memory consumption
- Smaller administration team
- Complex management
- Collaboration and analytics are problematic
3. Shared tables
In this model the same database and same tables are used for hosting multiple tenant’s data. A table would include records from multiple tenants stored data in random order and each tenant record is identified using a tenant ID column , as record is linked to its appropriate tenant.
Shared table: Pros and Cons
- Updates apply automatically to every tenant at the same time
- Application vendor can easily support any software capabilities which require a common query to be triggered across multiple tenants
- It is simple to manage as there is only one version of production at any point of time
- Easier integration with back end infrastructure
- Isolation issues
- Security concerns and vulnerable to certain attacks like SQL injection etc.
- Slowness issue
There are economic considerations when choosing the approach , a shared approach with optimized application requires larger development efforts than applications designed using an isolated approach (Due to complexity of shared architecture) which would result in higher initial costs however ongoing operational costs tend to be low.