Cost per feature vs. cost per tenant (or how to choose whether to go multi-tenant or not)

If I was given a penny for every time I was asked whether it is better to use 1 database per customer (isolated data layer) or 1 database for all the customers (multi tenant data layer) I could retire in a tropical island without worrying about money for the next 5 generations. Note that I wrote "asked" not "answered"... hence why I am still working at Microsoft :)

The answer is of course quite complex and is related to the "multi-tenant efficiency continuum" Fred and I described in our various whitepapers. Below is a high level model introducing the notions of "cost per feature" and "cost per tenant" which I hope will help people find the answer to the optimal isolation/multi-tenancy mix.

If you find it useful, don't forget to send me a penny...

 

Cost per feature

The cost per feature is defined as the overall cost of implementing a specific functionality. This cost is mainly the time spent by the development team to design, implement and test that particular feature. As a rule of thumb, the simpler the feature, the less time is required for developing the feature, the lower the cost. Adding the multi-tenancy requirement to a particular feature makes it more complex to implement and therefore drives up the cost of implementing it, as more time will be spent in architecting and implementing it.

So, due to its additional requirements, multi-tenancy has a higher cost per feature value than isolation. The more the architecture is optimized for sharing, the more costly it is to develop. 

Cost per tenant

The cost per tenant is defined as the overall cost for delivering the SaaS application to a specific tenant. This is mainly the cost of the operational infrastructure required to serve a tenant. This amounts to the cost of the physical servers, the licensed software such as operating systems and databases, storage, bandwidth, electricity as well as the people operating and supporting the software.

A multitenant architecture maximizes the sharing of resources resulting in a higher density of tenant per physical server. This higher density results in a lower cost per tenant. Vice versa, an isolated architecture will have a higher cost per tenant value.

Looking at these over time

The previous two sections showed how multi tenancy incurs a higher cost per feature, but lower cost per tenant while isolation has lower cost per feature but higher cost per tenant.

The figure below plots the cost of the two approaches over time. Note that this figure is meant to illustrate the concept in a qualitative way, not quantitative.

The blue line represents the multi tenant approach, whereas the red line the isolated approach. During the development phase (up to t1 for the isolated approach, and t2 for the multitenant one) the leading cost is the cost per feature. Initially, due to its higher complexity, the multi tenant approach has a higher cost and takes longer to complete (t2 after t1). However, once the application is put in production and the tenant base grows, the isolated architecture increases faster than the multi tenant one. Eventually, the cost of the isolated architecture will surpass the multi tenant one.

A few key points and caveats for this diagram:

• Multitenant architecture has a longer time to market (t2 > t1)
• There is a multitenant architecture “tax” to pay at the beginning, hopefully recovered in the long term through a lower cost per tenant
• The multitenant long term benefit (t3) requires the tenant base to grow large. The cost per tenant difference will overcome the higher cost per feature only if the solution is used by many tenants (long tail).
• The difference in cost per tenant can largely vary based on the situation. It is possible that the cost of tenant difference be small

In summary, as a rule of thumb, in it worth investing in the higher cost per feature of multi tenancy for a particular aspect of the architecture, if (a) the tenant based is expected to be high (b) the resulting difference of cost per tenant will be large. The corollary is that if the resulting difference in the cost per tenant is low, there is a low incentive from an economical perspective, to invest in the multi tenancy route.

Comments

• Anonymous
  January 25, 2007
  The comment has been removed

• Anonymous
  January 26, 2007
  Hi Sinclair, As mentioned, this is a first degree approximation of a few concepts. It is likely that polynomial or exponential behaviors occur over time in the “cost per tenant” curve giving an increasing edge to the multi tenant approach, but I did not want to introduce too many subtleties in the graphs without any hard data. With regards to other factors to consider, you are right, there are many other factors one has to take into account when deciding where to fit in the MT continuum. Examples of these are as you said capacity of meeting SLAs, compliance to regulation around ownership of personal identifiable information… but one could argue that all these could be “architected in” resulting in a higher “cost per feature”. What I am trying to say is that as a first approximation, everything can be equated back to cost. Thanks, --gianpaolo

• Anonymous
  March 01, 2007
  Gianpaolo Carraro has a great post on the question of whether to go multi-tenant or not - it is a must

• Anonymous
  June 20, 2008
  I was reading Why multi-tenancy matters and Many degrees of multi-tenancy today and honestly, I am still