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:

• Instance sharing: Instance sharing can be done, 1) only at the database server level or 2) both at application and database server level. Of course, more sharing means more savings which can be passed on to customers resulting in lower cost of service. But more sharing also means that more upfront thought has to go into architecture and design of the service since any problem with the shared instance will affect multiple tenants. This higher upfront investment can have a huge long-term payoff though by reducing the operational cost (and hence total cost of ownership) of the service.
• Database schema sharing: If instance sharing is implemented at the database level, then within the same database server instance, 1) a separate database user schema can be deployed for each tenant or 2) all tenants can share a common database user schema. Common database schema is more cost effective but can be challenging to implement and optimize. Handling custom extensions for each tenant can make this even harder to implement. One way to deal with this is to drive functionality based on meta-data. Each tenant can inherit the common meta-data and define its own meta-data on top of that to support tenant specific extensions to processes and policies. This is how Salesforce.com is designed. Database partitioning strategies can be implemented for better performance. Data is usually partitioned based on customer ID (Tenant ID) to keep all the data for a given customer in the same partition for performance reasons. A certain number of predetermined tenants live in each partition. The extent to which tenant specific extensions need to be supported depends on the nature of the service as mentioned earlier (e.g. email vs sales force automation)
• Application code sharing: If instance sharing is implemented at the application server level, then within the same application server instance, 1) separate code modules can be deployed for each tenant or 2) all tenants can share the same code module deployment (e.g. war file). Again, more sharing means more savings but the operational issues have to be kept in mind and lot of thought has to go into architecture and design of the shared application. All the rules should be externalized so that tenant specific extensions to processes and policies can be incorporated in the shared codebase. Application partitioning strategies can be implemented to improve performance and scalability of shared applications. Multiple partitions can be created to support large sets of tenants. Requests can be routed to the correct partition based on tenant ID and/or other predetermined criteria.

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.