Multi-tenancy was a relatively new concept back in 2010 when I was writing the dissertation report for my MS. This extract from the report aims at providing a clear understanding.

Multi-tenancy is an architectural pattern in which a single instance of the software is run on the service provider’s infrastructure, and multiple customers, or tenants, access the same instance. It is an organizational approach for SaaS applications today. SaaS-based software providers are believed to have evolved from Application Service Providers (ASPs) from the previous decade, which differ from today’s multi-tenant applications which are provided via a software-on-demand model specifically designed for SaaS distribution. Although the interest in this concept is rapidly growing since its inception in 2005, research is relatively slow.

Key aspects of multi-tenancy

• The ability to share & optimize the use of hardware resources
• The ability to offer of a high degree of configurability
• The architecture to support the use of a single application and database instance to serve all tenants
• Cost benefits from economy of scale & improved utilization
• Ease of deploying a single instance
• Simpler management
• More frequent releases with bug-resolutions & new features
• All customers are upgraded at once
• Reduced operational costs
• Easier to scale-up with the advent of cloud computing

Benefits of multi-tenancy

• Cost benefits from economy of scale & improved utilization
• Ease of deploying a single instance
• Simpler management
• More frequent releases with bug-resolutions & new features
• All customers are upgraded at once
• Reduced operational costs
• Easier to scale-up with the advent of cloud computing

Degrees of multi-tenancy

There are several degrees of multi-tenancy depending on the design and strategy used to develop and deploy SaaS applications. These approaches are basically variations between isolation and sharing of data as extremes. Yet, they all use a single instance of the application code. The three variations can be summarized as follows:

• Separate Databases
• Shared Database, Separate Schemas
• Shared Database, Shared Schemas

The final approach, also known as the shared table approach, is the one that delivers maximum savings. Though ideally all SaaS vendors should seek to achieve the highest degree of sharing for maximum benefits, it may not always be possible. The customer based on their security needs may demand separate databases or a certain application stack. While customers are willing to bear the additional licensing costs, the application must support it. However, there are a few other notable challenges with this approach that we will discuss in subsequent posts.

This post is part of the SaaS Application Development series, extracted from my final dissertation submission at BITS, Pilani that closely looked at rapid-development of SaaS-based applications.