Multi-tenancy: are they selling you a pup?

When vendors step up and argue that multi-tenancy does, or doesn't, matter, the most important question from a buyer's point of view is, what's their agenda? They wouldn't bring it up if they didn't believe it might aid their sales spiel. In this posting, I'm going to run through three common scenarios, in each of which the answer is different.

But first of all, let's put this whole debate into perspective. The cloud operates within a service-oriented architecture, where providers achieve economies of scale by delivering their services in volume and operating them from pooled resources. You shouldn't have to care how they pool those resources behind the scenes so long as they fulfil their service contract with you. Each service is a 'black box' whose inner workings are the sole concern of the service operator, so long as you are sure of two key factors:

• Governance: nothing will happen to your data or processes that breaks your own rules governing how they should be handled.
• Sustainable advantage: bluntly speaking, the provider hasn't sold you a pup that won't live up to its promises or will rapidly cease to be competitive.

Governance should be covered in your service contract. If your due diligence tells you the provider can be trusted to fulfil the contract, then it's as simple as that. Assessing sustainable advantage is a little more tricky. Trust plays a big part, but the other factor here is your evaluation of the provider's capabilities. It's during this evaluation that the multi-tenancy question may loom large.

Case 1: Conventional vendors moving to the cloud
Ever since cloud became a must-have offering, established software vendors have been eager to define it in the image of their own existing product architectures. Not surprisingly, then, these are the vendors who will tell you multi-tenancy really isn't that important. Many have used terms such as 'mega-tenancy' to excuse them from building multi-tenancy all the way down into the database layer (for more on this, see Many degrees of multi-tenancy and Taking false cloud comfort from multi-tenancy). The refrain is just as strident today as ever, whether it's Unit4 Agresso claiming to have reinvented cloud multi-tenancy [sigh] or Oracle arguing that multi-tenancy no longer matters.

Given where these vendors are coming from, laden with legacy baggage, it's easy to dismiss these arguments as cloudwashing. But is there any merit in what they say? Here are the main arguments they advance:

• Today's automation and virtualization technology makes multi-tenancy moot. It's so fast and cheap to spin up virtual database instances that there's no point in taking multi-tenancy right through the stack.
• Modern remote management and automated updates allow us to keep all our instances in sync without having to centralize everyone on a single, shared stack. We can even remotely monitor our customers' usage and aggregate data if they let us, giving us much the same oversight as a fully multi-tenant SaaS vendor.
• We don't want to co-mingle your data for governance reasons.

All these arguments sound reasonable, although the one about co-mingling is easily dismissed. Nevertheless, the increasing sophistication of virtualization, automation and remote management technologies have certainly allowed conventional architectures to catch up with some of the economies of scale of full multi-tenancy. But is it enough? You can see why they would want to believe it is, and if you're a long-term customer you may feel there's value in sticking with the 'devil you know' and that is already installed in your own data center, even if they are cutting some corners. The danger is that they're indulging in wishful thinking rather than delivering a sustainable, competitive advantage.

Case 2: Established cloud application vendors
From the earliest days of cloud applications, vendors such as Salesforce.com, Workday and Successfactors have built their applications completely multi-tenant from top to bottom, with a single, shared database as the foundation layer. Unsurprisingly, these vendors insist that multi-tenancy is the cornerstone of how the cloud operates.

The way they use the database is very different to a classic client-server architecture. It consists of a small number of extremely large tables, with the data model and application code mostly stored as metadata rather than being coded into the database. In addition to saving on database licenses, this approach delivers huge economies of scale in achieving high performance with low operating costs, as the entire stack can be optimized to maximize efficient resource usage. Since all customers and ecosystem partners are always running on the self-same operational platform, there are additional benefits that come from collective, pooled innovation on that platform.

These vendors argue that the economies of operation and the rapid pace of collective innovation are so great that you can never achieve the same effect simply by implementing virtualization and automation within the infrastructure of a conventional client-server architecture, no matter how cleverly you do it.

Some critics, however, have argued that these vendors had no other option when they started building their cloud applications ten or more years ago, before virtualization and data center automation reached the levels it has attained today. The choice they made then has locked them into a single, bloated platform that they have no option but to keep extending, leaving their customers locked into paying for platform functionality they may not need or want.

Case 3: Next generation cloud vendors
When you realize how little the latest generation of cloud vendors mention multi-tenancy, you might begin to suspect that the entire debate between conventional and first-generation cloud vendors is becoming an irrelevance. It's about two different approaches to building a class of applications that perhaps shouldn't exist any more anyway.

One of my Enterprise Irregulars colleagues, Esteban Kolsky makes the argument that multi-tenancy matters less in the cloud because (as I understand it), rather than being a monolithic entity, a cloud application is made up of a loosely coupled collection of services that are orchestrated together to deliver a result. If the automated infrastructure decides that it's faster and cheaper to bring up a service on a single-tenant virtual instance rather than using a slice of an existing multi-tenant instance, who really cares? Multi-tenancy just becomes one instrument in the toolbox rather than a critical, defining feature of the entire architecture.

Here's a potential case in point. One of the clients I work with has just started shipping the first production servers based on low-power ARM processors. These servers are said to operate with one-tenth the energy requirement of conventional PC architecture servers, but they are 32-bit processors and the maturity of the software today means you'll currently get more out of them by running a dedicated process on each core. This is an example where provisioning dedicated instances today for a 10x cost improvement could be a better choice than engineering a multi-tenant implementation for certain operations.

Overall, though, it seems to me this argument is splitting hairs about the meaning of multi-tenancy. If, for example, Google Compute Engine provides resiliency against data center failure by distributing processor loads using a single-tenant management tool called Spanner, is that really relevant to the discussion we started with? The Compute Engine is still a shared service at the point of use, with none of its infrastructure components dedicated to an individual customer outside of Google itself.

Ultimately, you shouldn't have to ask about multi-tenancy when evaluating a cloud application or service because it will just be there in the infrastructure. But until we reach that level of cloud maturity, buyers of enterprise applications must be ready to evaluate the multi-tenant credentials of vendors as part of their due diligence. If a cloud application provider has single-tenant components in its infrastructure as a hangover from a previous architecture, it's likely that choice has been made because of its history, rather than after a full evaluation of the economic, performance and change management implications for the cloud service. What really matters is whether the cloud provider offers economical operation, rapid innovation and competitive operational performance. Providers will be judged on their track record. Until they've established that track record, it's a case of caveat emptor; buyers must make their own judgement.