There Is No Multi-Tenant Architecture: There Are Three!

I’ve heard the term “multi-tenancy” hurled at somebody as an attack about once too often now. Could we at least agree that there are several different kinds (I count three) of multi-tenancy, and they have different tradeoffs?

1. Application-level Multi-Tenancy

Salesforge, Gmail, and most SaaS businesses come to mind: they run all of their customers on a single application (and database) instance. Or if they run multiple application instances, many customers are assigned to the same instance; no customer on the same plan has any particular computing resource with their name on it.

2. Hypervisor-level Multi-Tenancy

IaaS vendors like Amazon Web Services, Rackspace, GoGrid etc. practice multi-tenancy at the opposite end: multiple tenants share the same hardware, but each of them has an entire (virtual) computer for them with separate instances of operating system and applications.

3. Middleware-level Multi-Tenancy

And then we have something in the middle. Some of the Platform-As-A-Service products like Heroku do this: each customer runs their own application, but all share the same hardware and operating system. Good old-style shared hosting is also in this camp.

[4. Others

For completeness, a colocation facility with hardware from different customers would also use the label “multi-tenant” with justification: multiple customers, aka tenants, rent space in the same data center and share the facilities. That’s usually not what we mean in computing, but that’s what the word means originally!]

It’s obvious also that these different versions of multi-tenancy have different pros and cons:

• Application-level multi-tenancy is probably the most resource-efficient: there are no copies of anything. The downside is that all of those customers really better have the same requirements, because customer-specific changes are, by definition, impossible: everybody must share the same code.
• Hypervisor-level multi-tenancy has copies of operating system, middleware and applications for all tenants, so it’s less efficient. But then, these customers can do pretty much anything they please and won’t step on each others’ feet.
• Middleware-level multi-tenancy is somewhere in the middle, having all the drawbacks of application-level and none of the advantages of hypervisor-level multi-tenancy (or was it the other way around? ;-) just kidding)

So next time somebody screams: “but it’s not multi-tenant, so it isn’t cloud!” (ignoring that we have even less of a clue what “cloud” might be) let’s politely respond: which kind of multi-tenancy does it have to be for you? It seems to me that all of them have their justifications …