Multi-Tenancy – A Pragmatic View

A few weeks ago while searching for an appropriate definition of ‘multi-tenancy’ to quote; I found that people and organizations had differing opinions of what it really means. Even the Wikipedia article claims that the “… principle of multi-tenancy is not universally accepted and supported within the software industry, and this may be a source of competitive differentiation.” No Kidding! In this blog, I think we need to differentiate fundamental multi-tenancy from more cultural, more ambiguous uses of cloud computing.

I think this is true: The definition of multi-tenancy is just evolving. Much like the term “cloud” has changed as numerous vendors try to compete on their own terms; the definition of multi-tenancy has been changed, abstracted, and reapplied. Some would argue that multi-tenancy requires the cloud to exist. This leads to all sorts of confusion as two ambiguous terms are used to define each other

Rather than a literal definition, I would suggest a pragmatic approach to answer what multi-tenancy is. For example, some of the best examples of multi-tenancy are fundamental programs, such as VPEP, that can be configured to run a single isolated instance of an application, and at the same time, are designed and have the capacity to service many customers (multi-tenants) uniquely. The key point is that a single instance of an application, such as Squid, can uniquely service multiple clients: “VPEP has enabled Squid to operate at six times its native transaction load, for example, on a single 8-core server – allowing one company to shrink its equipment need by roughly 75% and overall operating cost by more than 60%.”

I mention VPEP as an example of a solution that supports the multi-tenancy of unique applications. Here VPEP defines multi-tenancy with their pragmatic approach: “Even single-tenant, single-threaded applications can be delivered efficiently from a single server to many separate tenants, with each tenant enjoying application configuration and control. This makes it economically viable to serve single-tenant applications from the cloud without re-architecting the application for multi-tenancy.”

I’ve heard other arguments, such as from Salesforce.com for example, of where you can perform customer relationship management in a multi-tenancy configuration. In “The Force.com Multitenant Architecture: Understanding the Design of Salesforce.com’s “Internet Application Development Platform” , the definition of multi-tenancy is given as: “Tenants using a multitenant service operate in virtual isolation from one another: Organizations can use and customize an application as though they each have a separate instance, yet their data and customizations remain secure and insulated from the activity of all other tenants”. The single application instance effectively morphs at runtime for any particular tenant at any given time. If a Salesforce user is secured away from other clients, each instance presumably walled off from another – the argument goes – and therefore Salesforce is a multi-tenant application.

That argument holds if you think any collection can be multi-tenant. A rental housing multiple students, a sailboat with multiple mates, a barrack filled with soldiers, or a street lined with houses, are all examples of this kind of multi-tenancy. Even the argument that any server can have multiple virtual machines running falls into this description. I think it is more related to SaaS and the Cloud than multi-tenancy.

In summary, I believe the Salesforce-like example described above leads to some incongruity and is fundamentally different from the more fundamental VPEP approach to multi-tenancy. VPEP’s goal seems focused on delivering very efficient, economically viable multi-tenancy from applications that might not be architected to run concurrently. They are provisioning a true multi-tenant environment, that sounds right and can be differentiated from a SaaS-like, fully provisioned infrastructure whose applications are designed to run multi-tenants.