Multi-tenancy – Do I Need It?

July 7, 2008 at 4:05 pm Leave a comment

At Patni, one of the things I am responsible for is structuring our service offering around SaaS and going to our customers to understand their SaaS related initiatives and discuss how SaaS can play an important role (or not) in their product or enterprise strategy going forward. As part of this initiative, I am often asked the question – “how do we architect for multi-tenancy and how do I know if that is the right approach for me?”. Some customers want to do multi-tenant architectures because they feel it is a buzzword that needs to become a part of their marketing collateral when they market their SaaS product to customers. Some feel that it is absolutely needed from an architectural perspective for their product to scale. Every customer has their own views and perspective on this and it is interesting to have these discussions with them and walk them though why it might or might not be critical to design a multi-tenant architecture each and every time.

First of all, ISVs needs to realize that their customers don’t care about multi-tenancy. Their customers probably have not even heard of that term, talk less of knowing what it actually means. All the customers care about is consuming the SaaS product and paying a subscription fee or having to view ads (whatever the monetization model might be). So, from a consumer perspective, multi-tenancy holds no water. They simply don’t care. But from a provider perspective, it might be very important. Not every SaaS implementation has to be multi-tenant. Yes, it is often highly desirable to pursue a multi-tenant architecture to achieve economies of scale. However, before embarking on designing such an architecture blindly, it is useful to analyze and understand the pros and cons of a multi-tenant vs. a single instance architecture.

At it’s core, building a out a full scale multi-tenant architecture means giving a great deal of thought on the overall database architecture, the resulting schema, the way the code has to be written to leverage the additional primary and foreign keys, thoughts around additional code for security now that data is shared, and much more. In essence, following a multi-tenant architecture means more complexity and costs up front. This is very similar to building a SOA based application. There is more work involved in baking in all the though around common services at development time. On the other hand, the costs of building out an isolated architecture.

On the flip side, a multi-tenant architcture, by its very nature is centered around economies of scale. This means that hosting and managing a multi-tenant architecture should result in cost savings when it comes to infrastructure, utilities and man power. This is the exact opposite of an isolated architecture, which typically needs dedicated databases, more servers, higher energy bills and more man power to handle all that complexity.

So it is important to realize that multi-tenant is more than a buzzword and as such, should not be blindly baked in to any product. It has real consequences (such as increased time to market for a product that needs to implement multi-tenancy upfront due to increased upfront complexity). Analysis needs to be done on the tenant population in terms of numbers of tenants, pricing strategy of the ISV for this new product, etc to determine if that increased upfront cost will be met based on how many tenants will subscribe or if the pricing is in line with the costs associated with the complexity. If the number of tenants might be small or the pricing cannot be set at a level where the breakeven might be achieved in a short timeframe, then there might not be a real incentive to go multi-tenant. Furthermore, there are other ways to achieve economies of scale by using virtualization and cloud computing, so those too need to be factored in when making such decisions.

Bottom line: yes, multi-tenancy is a very important concept for many ISVs, but it is a concept that needs to be thought out from many different angles before deciding on whether or not it should be an integral part of your product architecture.


Entry filed under: Architecture, SaaS. Tags: , , .

Monetizing Social Networks – Part 3 Cloud Computing – An Intro

Leave a Reply

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

You are commenting using your 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

Trackback this post  |  Subscribe to the comments via RSS Feed

Add to Technorati Favorites
July 2008
« Jun    

Recent Posts

%d bloggers like this: