The “multi-tenant” emperor has not clothes

In the last few weeks I have read quite a few articles (and blog entries) glorifying multi-tenancy, how it will solve world hunger and bring peace to the world.

Don’t get me wrong, I am a BIG FAN of multi-tenancy and fully comprehend the value of architecting SaaS solutions in a single instance multi tenant way (if you don’t believe me, just go here and I am on record saying that I am a big fan J) however I would like to make sure that people understand that multi-tenancy is 100% a SaaS delivery aspect. When you consume SaaS you don’t care whether the service is multi-tenant or not; actually to be honest many would rather prefer consuming a single tenant architecture so their data is not co-located, the data model can be more easily modified, the SLA can be more easily guaranteed etc. (or at least so they think). By reading our papers, you all know by now J that all these aspects can be architected in a multi tenant environment (but this is a tangent).

IMO the ultimate trick is to be multi-tenant without anybody knowing it J in other words having people experience single tenant behaviors out of a multi-tenant environment. Hence the importance of the metadata service we described in our first paper on SaaS architecture.

Allow me the following analogy: not too long ago I went to a very good restaurant serving great food, I didn’t ask them how many cooks were in the kitchen, whether they used 20 years old pans or when they last sharpen their knives… I enjoyed the food assuming that the Chef put her entire dedication to prepare my dish (even though I saw the same dish served at table next to me at almost the same time)

So, from a service consumption perspective (i.e. what people who actually pay for the service do) the important aspects should be: the functionality of the service (how well the food taste), how much I can customize the service (can I have the dish low in salt) the SLA (how diligent is the maitre d’ and how long I wait in between dishes) and the integration APIs (how well I can marry the dish with the special wine I brought with me (the restaurant had a friendly cork policy)) .

That’s it. Everything else is (at least in theory) none of my business.

For SaaS providers learning and mastering the art of multi tenancy is critical, promoting that skill in the marketing brochure is a little bit like a Chef saying: “I cook with very sharp knives” (not very interesting, if you ask me)

I know this is not what happens out there, where enterprises as part of the due diligence ask questions about the internal architecture and ISVs as part of their “branding” show off their architectural capacities. But think about it: if we like the feature set provided, can trust the SLA that is given to us, understand what/how we can customize and know how to integrate/compose, all that at a price, that makes sense; why would we bother asking whether it is multi-tenant or not.

Just to make sure I am not confusing anybody, I want to reiterate the reason why SaaS providers (the one who deliver services) are well inspired to aim for multi-tenancy. Multi-tenancy (done properly, i.e. including the appropriate metadata for customization and proper scale (out) mechanisms) offer an economy of scale that cannot be equaled by a single instance environment and enjoy an operation cost structure lower than single tenant architecture. It is that economy of scale and lower operating cost that allow providers to address the long tail and/or undercut a competitor price and/or have higher margins. In other words multi-tenancy allows better (delivery) business models, and should not be pitched as a technical superiority in a consumption scenario.