The Unbearable Lightness of Multitenancy in the Cloud

If y’all are not in the mood to listen to a (well reasoned, researched, educated and well-timed) rant, move along.  This is me ranting about vendors trying to confuse users when it comes to cloud topics.

If you are interested in why multitenancy should not be an item of discussion, then read on.

Consider y’all warned.

Last week (and into the weekend) the Enterprise Irregulars community got lit up.

These are rare occurrences these days, as we have probably dealt with most issues in many different ways and we are used to — well, just about anything.  However, this one was an interesting discussion.  SAP announced last week that it would move their SAP Business One offer to the cloud.  Part of the announcement was that there would be multiple instances of the solution available (SAP Business One is a partner-provided solution; each partner runs a different instance which they customize, add to, and manage).  As Dennis Howlett astutely points out, nowhere in the announcement talked about multitenancy, so the speculation among the EI started on whether  each instance will be multitenant and how.  Someone (and I cannot find the right reference to where it began) called it “megatenency” – as in multiple instances of multitenancy managed with systems management as a single one.  Just thinking about that makes my brain hurt in a bad way.

This brought the discussion, as it always does these days when a vendor announces their own spin of cloud and multitenancy, of whether it was real cloud and how they can call it cloud if it does not support multitenancy.  This is usually the spot where I bite my lip, work through the pain and try to ignore the discussions.  Unfortunately, I cannot bite much longer – pretty sore and bloody…

There is a commonly held belief among people in this world that nothing can be cloud without being multitenant.

A horribly wrong belief.

Multitenancy is a leftover from hosted applications times.  Back then (when applications were massive and complex, not distributed, and basically just offered a web-interface to a client-server or similar solution running in the data center) there were few ways to make sure a vendor offered the same  version of the solution to each person who worked in the hosted model: offer multiple interfaces to a single instance of an application and take appropriate precautions so each person using the application would see a personalized (to a certain extent, not everything can be personalized in a hosted application) version of the same application.  This made administration of the application easier (can you imagine having to apply a patch or a new parameter to 1,000s of replicas of the same application?) for the vendor (also far cheaper as they did not have to pay for multiple instances) and guaranteed the user would always be running the latest and greatest version of the application without even thinking about it.  Along the way, and as we progressed to trued cloud solutions, multitenancy became the crying battle for what cloud applications should be and how all vendors should be judged as being “true cloud” or not.

You are probablly sitting there and nodding your head, saying “yes, that is what I know to be certain”.  Except that it is not.

True cloud computing does not care about multitenancy.  To paraphrase a popular line from the movie “The Matrix” — once you are in cloud computing, you won’t care if it is multitenant or single-tenancy; there is no “spoon”.

To see cloud computing in better perspective, don’t think of large applications – think of your smart phone (I almost said Android instead of iPhone when referring to smart phones, but did not want to start that war between toy and phone – know what I mean? different rant, different day).

In the cloud, all applications SHOULD be like your smart phone apps: small, single-function, easy to build and deploy, and easy to manage (via App stores or marketplaces).  If you think of the cloud that way, you quickly begin to realize that multitenancy does not matter in the cloud: regardless of where the app is, it is not hard to keep always the latest-and-greatest one deployed (my Android updates all my apps automatically, sans a few — but that is a human-introduced issue with DRM and pseudo-privacy, not a cloud problem).  I don’t worry about my data being shared or not (one of the many, also wrong, complaints of those that don’t care for multi-tenancy) since I store it where I want to, use it as I want to, and control it as I want to.  The brunt of the application, the work to be done, happens in platforms across the world – platforms that perform commands in coordination with an Infrastructure layer and a Software (which should actually be called presentation) layer.  By definition, you can replicate  infrastructure, platforms and software ad-nausea in the cloud and never have to worry about tenency (systems management, another issue – far more complex and one to which Microsoft made no favors by introducing their SMS product in the late 1990s – what a flop and improper use of the term; slightly better today, but damage was done).

Hope you can see the difference between hosted applications and a true distributed architecture like cloud computing (especially when it comes to multitenancy).  I hope you can see why multitenancy is something that, once you are in the cloud, it does not matter — unless you deploy hosted applications, called them cloud, and want your customers to discuss something that is remote from what they should be discussing and educating themselves about: true cloud computing architecture and how to deploy that in their organization.

Multitenancy discussions when talking about true cloud computing just distract from the issue and I wish the vendors would get smarter and stop using that legerdemain to hide that their solutions are not really, truly, cloud-compliant.

Of course, that is just me — the cloud purist.

What do you think?

(BTW, as I was getting ready to push this out Dennis wrote another interesting post, check it out - he says that the discussion on multitenancy matters)

Disclaimer: SAP is a client, but it does not matter for this post as I only mention them in passing and make no statement either in favor or against their actions.  Just sayin’

10 thoughts on “The Unbearable Lightness of Multitenancy in the Cloud”

  1. Preach it! I agree, multi-tenancy means nothing… to the CUSTOMER. What I always find interesting is how people almost always leave out the importance of “which point of view” in this discussion. For VENDORS having a single infruastructure to update (think Gmail or Saleforce) which applies to multiple customer at a single time is a great thing, as it saves time and money. However, the customer rarely cares about multi/single tenancy (or even understands) and would most often prefer their data NOT be stored on the same system as other customer if given the choice. Great post.

    1. Data residency is a different issue, one with legal ramifications that unfortunately cannot be bent. Given choices, I rather not store my own data anywhere near me.

      I like the announcement, waiting for the solution now, on RDO from SFDC last year at Dreamforce. Let’s see if it takes and where it goes from there, then we can have better debates about data ownership and residency.

      That is just me, what do I know?

  2. Right on target Esteban – the world is full of opportunities against competitors who are not basing action on validated customer needs, but rather a set of assumptions about those needs. Multi-tenancy is a prime example of this that I have come across myself several times in discussion with prospects & customers.

    1. Thanks for reading and commenting,

      I hope more people like you who went through this and came to the conclusion on MT on their own would speak up. Sometimes I feel like Don Q waving at windmills like a madman :-).

  3. Those who don’t know what multi-tenant means and why it is beneficial probably don’t care – and admittedly that is a large population of buyers. But I can tell you from experience that customers who have experienced success with multi-tenant cloud applications DO CARE. Sometimes it’s hard to get past all of the marketing rhetoric around cloud and multi-tenancy, but once you have experienced results in weeks vs months or gone through that first upgrade cycle where new features are suddenly available without having to do anything, you start to understand that the world of multi-tenancy is not just marketing hype – it really does drive business value.

    1. Nick,

      I agree that people want benefits, but what you mention is not a result of multi-tenancy. It could be done, better and simpler, without multi-tenancy. In my example above I use smart-phone apps as examples, are they multi-tenant apps? no, they are single-purpose cloud apps that leverage resources without worrying about the being MT. Making MT matter for cloud apps IS a marketing scheme that delays adoption of cloud computing. Everything you mention above is certainly doable w/o MT and performance (at the very least) will be better.

      MT, same as private cloud, are not cloud concepts, but we use them to ease the transition for vendors. It is prohibitively expensive to migrate from non-cloud to true-cloud architecture for a vendor, and MT provides a simple way to do that without rewriting massive amounts of code and changing architectures. There are marketing terms for cloud concepts, and most of them reflect a hosted app architecture that is not cloud-compliant but cloud-like. This is the first step for the market to mature, and we are starting to see a second step with new vendors going closer, if not entirely, with cloud computing and bridging the gap with many different models. We will see a third and possibly fourth generation before we settle in a true, distributed computing, cloud-based model. This is normal evolution.

      Alas, in the way the old concepts and the bridges we built between the two are called things that are not necessary — MT and its imperative presence in cloud is one of them. I hope, and work towards, reducing that or hopefully eliminate it.

      Those clients you cite above would be equally happy with a true single-instance, single-tenant, fully replicated, elastic, and true-cloud solution as long as the answer to them is the same and it is same or lower price. That is where we are going, in few years (as Bill Gates likes to say – more than one, less than 10).

      Thanks for reading.

      1. One key point is that MT is the key enabler for the scalability and resource pooling that you cannot achieve at the same price point as a non-MT solution. Sure, a customer wouldn’t care if they could get a solution that acted the same as a MT app at the same price point, with all of the same benefits – but that just doesn’t exist. I’d love to hear an example of another non-MT offering that can do what Salesforce does as well as Salesforce does it – from customization, to upgrades, to scale, etc. If customers PREFERRED non-MT, I’m sure that solution would have a lot more traction than SFDC does right now.

        Also, don’t discount what a MT solution does for the provider’s channel of partners, which in turn benefits customers by giving them greater choice. Partners don’t need to support 20 different versions of an application, making it much more predictable and less expensive to manage.

        I understand where you are coming from with this argument, but my experience in implementing MT solutions for hundreds of companies tells me that Phil Wainewright is more closely aligned to what I see in the field with his “One resource for all” description in this ZDNet post i.e. he confirms my bias :) http://www.zdnet.com/blog/saas/taking-false-cloud-comfort-from-multi-tenancy/1530?pg=1

        1. Nick,

          I commented on Phil’s post similar to what I am going to say here: I am not discounting the argument for MT as a transitional strategy; it works, is cheaper, and we all know how to do it for now.

          However, most of the smaller startups i talk to these days are not even considering MT as a solution because better and cheaper resources are becoming available. Then again, none of them are even interested in going after SFDC in the breadth of functions and solutions offered. And that is the truer model of the cloud – SFDC and the other vendors we are using today cannot function in a cloud model: too complex, too interdependent, and too expensive to put in the cloud. Cloud was never meant to take an app like SFDC and serve it to millions; that is what hosted apps does far better.

          Cloud computing relies on service calls to small functional components; once you have access to many of them, you can build a more complex solution if you want – or simply do those few functions you do. I’d love to find even one company that uses more than a percentage of functions offered by SFDC (I never found more than 20-25% in the old SEBL days for them, found a few people that are nearing 40% for SFDC). The question always comes back, why pay and deploy components you won’t use? Because, until now, they were not available in other formats.

          Cloud computing is much more than being on the internet; those Microsoft and Apple TV ads are not helping with understanding what cloud is. For web presence, MT cannot be beat economically — but it is also not cloud computing per se.

          We can argue for years one over the other, and probably will — and hope by the time we are done arguing we will a true cloud computing model (what Phil calls “one for all” – with some modifications I’d like to add)adopted across the enterprise and the world.

          Will I be proven right at the end? hope so, probably not and probably more concessions will have to be made on the way — but my job is to advance discourse and show the way, highlight the battles worth fighting, and engage in the debates that make better solutions possible. Done quite well for the past 10-15 years, looking forward to the next 10-15.

          Thanks for taking the time, truly enjoying this.

    1. Lora,

      Thanks for the read, appreciate your comment. I’d say you are right (don’t forget to also update the NIST.gov definition while we are at it, already had that discussion on Twitter).

      From previous experiences with Wikipedia, I’m not even going to try that :-).

      Thanks
      Esteban

Comments are closed.