Architecting for Multi-Tenancy in the Cloud
Implementing a multi-tenant service
By: Vinay Singla
Apr. 26, 2010 05:00 AM
Why is Software as a service (SaaS) gaining such momentum? What makes the SaaS proposition so compelling? “Faster time to capability” and “lower upfront cost” are two of the main reasons for this. For any organization looking into adding a system capability, once the buy or build decision is out of the way and the decision is to buy, there are two choices; either buy a software package and deploy it on premise OR subscribe to a SaaS provider. Deploying a software package on premise is no simple task. It can take months or even years to go-live with full functionality and realize the ROI. In contrast, SaaS can provide full functionality in days to weeks.
The reason SaaS can provide such fast time to capability and low upfront costs is because of a shared service model where multiple customers share the same deployment of software. This is also known as multi-tenancy. Achieving multi-tenancy is not trivial and requires a lot of upfront thinking and architectural work. The complexity due to multi-tenancy can vary depending on the nature of the service. For example, in the case of an infrastructural service (such as email, instant messaging etc), all customers (tenants) would pretty much require the same set of functionality. In contrast, a business application service (such as salesforce automation) might have to support different business processes, policies and rules for different customers (tenants), which can make the service very complex and challenging to implement. Also, usually, implementing multi-tenancy in business to consumer (B2C) services is simpler than that in business to business (B2B) services, because B2C services are used directly by customers of the service whereas B2B services are used by end-users of customers, leading to an additional layer of complexity to manage. Further, implementing multi-tenancy for Platform as a Service (PaaS), what I like to call multi-tiered multi-tenancy such as the Force.com platform is even more complex. Here each tenant has multiple tenants in turn and each of these tenants might need their own extensions or modifications to the functionality!
So how is multi-tenancy achieved? A typical software application consists of an application tier and a database tier. Different strategies can be applied at application and database tier to support multi-tenancy.
The simplest approach to implementing multi-tenancy is to create completely separate instances of servers (application and database) for each tenant. With this approach, application code and database schema for each tenant are deployed on completely separate servers and there is no sharing across tenants except the common codebase and schema definition. Each tenant can potentially have its own extension of the code and database schema to support any difference in processes and functionality from other tenants, although it can get very costly to maintain tenant specific extensions. With this approach, even though codebase is shared across multiple tenants, the cost of deployment for each tenant can be pretty high which in turn will increase the cost of the service. One way to optimize the cost with this approach is to host multiple instances of application and database servers on the same hardware. This can be further optimized using server virtualization. This may be an acceptable approach if the number of tenants is expected to be very small.
A more optimal way of implementing a multi-tenant SaaS (or PaaS) solution is to deploy shared instances of servers across multiple tenants. This is where SaaS starts to pay off. With this approach, compute and storage resources are shared across multiple tenants resulting in lower cost of service for each tenant. Within this approach, multiple levels of sharing can be implemented to further reduce the cost of the service as follows:
In conclusion, there are multiple ways to implement multi-tenancy and the choice depends on the nature of service being implemented. It is very important to spend the necessary time upfront during architecture phase to determine the multi-tenancy needs and to come up with the best design for supporting multi-tenancy, depending on the current needs and future vision of the service. Once the approach has been decided and implemented, it can be extremely difficult and costly to change, much like converting a fourplex into a multiplex apartment complex can be an almost impossible task without starting from scratch.
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week