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

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).

Cost per tenant vs Cost per feature

  • 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.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: