Share via

The “multi-tenant” emperor has not clothes

  • Article

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.

Thoughts?

Comments

  • Anonymous
    August 30, 2006
    In my last company, where we hosted software in a multi-tenancy situation (this was from 97-2002), we definitely experienced what you mention:  if anything, our customers were concerned about multi-tenancy.  

    They would have preferred to have dedicated hardware for their systems.  We didn't offer that, though, because we need the economies of scale.  

    For our customers, branding was essential.  We were selling software that they were, in turn, reselling to their customers.  That software absolutely needed to have the look and feel of our customer's web site.  

    But we couldn't offer the software at low prices and dedicate hardware to each customer:  therefore, we used multi-tenancy.  Did our customers love that?  Probably not.  But did they like the software, and did they like the price we were able to offer them as a result?  Absolutely.

  • Anonymous
    March 24, 2007
    I've described several times in the past that service providers (typically ISVs) and service consumers

  • Anonymous
    April 30, 2007
    On April 17-18 I was in Santa Clara mingling with the international SaaS crowd at SaaSCon . There, Eugenio

  • Anonymous
    March 22, 2008
    PingBack from http://dinnermoviesblog.info/gianpaolos-blog-the-multi-tenant-emperor-has-not-clothes/

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

  • Anonymous
    May 26, 2009
    PingBack from http://castironbakeware.info/story.php?title=gianpaolo-s-blog-the-multi-tenant-emperor-has-not-clothes

  • Anonymous
    June 01, 2009
    PingBack from http://indoorgrillsrecipes.info/story.php?id=2864

  • Anonymous
    June 08, 2009
    PingBack from http://hairgrowthproducts.info/story.php?id=2819

  • Anonymous
    June 09, 2009
    PingBack from http://insomniacuresite.info/story.php?id=3290

  • Anonymous
    June 13, 2009
    PingBack from http://thestoragebench.info/story.php?id=2776