Software as a Service and more on choosing the right multi-tenancy model

I found Frederick Chong and Gianpaolo Carraro’s definition very simple and easy to understand.

"Software deployed as a hosted service and accessed over the Internet."

George Reese wrote about the key characteristics of a SaaS application from a consumer’s point of view in his book Cloud Application Architectures. Per George Reese the key characteristics are

• Availability via web browser
• On-demand availability
• Payment based on usage
• Minimal IT demands

  If we add the provider’s point of view multi-tenancy can also be considered one of the characteristics. But is multi-tenancy a required attribute of SaaS is debated in the community. Prakash has a summary of one such debates in his blog here. I’ll just quote Gianpaolo Carraro’s words here

  Multi-tenancy is a provider view of things, if you are a buyer of SaaS IT DOES NOT MATTER. It is equivalent to asking your utility company which turbine they are using to generate power, the only thing you care is getting 220V (110V in US), 10A, 99.99% of the time at a cost of  10c per kWh.

  I have written earlier about choosing the right multi-tenancy model here. I will expand on that thought in light of the understanding I gained from this debate

Criticisms about puristic shared everything multi-tenant systems 
• There is a cost associated in building puristic shared everything multi-tenant systems, which impacts the go to market timeline negatively.

The graph used by Carraro to explain the cost per tenant and cost per feature concepts (I could not find this image in Carraro’s blog now. Instead found it here).

• Bugs in multi-tenant systems where the database is shared could lead to other tenants seeing your data.
• Cost of scaling things which have state (yeah the database), ex: Licensing cost of Oracle Rack or the limitations of scale up options.
• If the tenants are big and you have only a few of them then you can do away with Shared nothing multi-tenancy and  per-tenant customizations (bigger clients typically need customizations) can be done on a shared nothing solution.

  A couple of things have changed in today’s context and we can look at these criticisms in the light of the changes and reach a reasonable compromise in choosing a multi-tenancy model.

One of things that’s true in today’s context is the availability of APaaS / CEAP / SEAP vendor services / products which reduce the cost associated with building multi-tenancy. As Gartner suggests Custom Multi-tenancy is not for the faint of the hearts. I also read a good discussion on Build vs Buy in Sinclair’s blog entry here:

Think of simple examples like giving your customers the ability to download data backups: is that an application specific problem or a “horizontal” problem for which a stack should be responsible? Do you want to waste effort on this or would it have been wiser to build on a PaaS that either has this functionality or that would introduce it faster than you would? I guess it wasn’t a one-time investment after all! In fact, it seems to be a massive ongoing investment with little predictability or bounds. This discussion hasn’t even touched on the maturity concept (for example, a “home built” SaaS stack will bump into security problems, bugs, etc. that get resolved in PaaS offerings much quicker because of the speed at which they scale due to aggregation, and the fact that PaaS providers focus solely on solving these problems).

So if we can spend a little money on a SEAP which enables multi-tenancy we can reduce the go to market time as well as cost than building multi-tenancy from the scratch ourselves.

The database scaling needs can be eased by using the current generation data stores which have in built support for scale-out / horizontal partitioning.

Per-Tenant customizations is a complex topic and I will write a separate post in that regard.

The Shared database security concern still holds and probably as of now Shared Processing model of multi-tenancy is a good bet. This is based on my current understanding, and I might change my mind in the future as I understand the problem better.

Choosing the right multi-tenancy model

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 Nothing	No	No	No
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.