There are various approaches to implement multi-tenancy in a SaaS application. We will use Gartner’s vocabulary defined here for this discussion – Reference Architecture for Multitenancy: Enterprise Computing "in the Cloud". For a really short and sweet discussion of these models please refer this blog post – If IT isn’t shared, it isn’t cloud…
|Model||Hardware / VM Instance||Application Instance / Process||Database|
|Shared Hardware||Hardware (Each tenant gets a VM instance)||No||No|
|Shared Database||VM Instance||No||Yes|
|Shared Processing||VM Instance||Yes||No|
|Shared Everything||VM Instance||Yes||Yes|
|Custom multi-tenancy||Hand rolled by the application not provided by an application platform|
Lets say we are building a SaaS offering on Windows Azure. Windows Azure itself can be categorized as a Shared Hardware Multi-Tenant Platform. It is easy to build a SaaS application in shared hardware model using Windows Azure where each client gets their own compute roles (web and worker roles) and an Sql Azure database. The problem with this approach is that it will work only if each tenant is large enough to warrant a separate compute instance (or a set of load balanced instances).
If each of your tenants is small, lets say you are building an accounting software as a service which will be used by independent accountants 1 tenant = 1 user in this case or small firms with less than 10 accountants. Spinning up compute instances for each tenant may not be economical. It will be wise to use the ‘Shared Processing’ model in this scenario.
Or in other words choosing a multi-tenancy model is not a pure technical decision, it is driven by the market too. If we examine why we are tempted to choose the ‘Shared Hardware’ here is because that’s what is offered out of the box by Windows Azure. Application Platforms which enable ‘Shared Processing’ or the puristical ‘Shared Everything’ are rare?/non existent today in Windows Azure space. Custom multi-tenancy is hard and is not for everyone to build.