Nov 022011

I keep reviewing so many documents in several stages. In more than once document, people keep on assuming that Multi-tenancy is not only desired, but also mandatory for applications to move to cloud. People, that is wrong notion. We are not in dark ages any more. If any multi-tenancy idea is old and should be moth-balled (except in specific cases).

Let me make the case for you.

Let us take a look at original server applications: your sendmail, your apache server, your ftp server etc. Each one of them supported some sort of multi-tenancy. Technically, we can assign multiple “names” to a single computer and we can make each of the services respond to that name it their own way. That is a virtual server comprised of all these virtual service. Of course, there is no partitioning of the computer.

What is wrong with it? Nothing, if all you want is to provide the services to different servers. In fact, you can take a look a virtualmin, a program that automatically creates the virtual services on various application servers like mail server, web server, db server and so on.


Let us look at the down side. You can configure the server with disk space and some other quotas. But, for most part, the sharing of the service is a really cooperative plan. If one of the virtual servers take up all the computing or networking resources, then the other servers will have to starve. Yes, some applications do offer support for fair scheduling, but it is awfully difficult to do that.

Then there are other issues: security, for one thing. Any bug in the app may leak the information to untended parties. If one of the servers want a new version of the server, no such luck.

When we say an application is a multi-tenant, this is the property we are referring to. That is, a single instance (or a set of instances) serving multiple clients, especially, each client getting their own virtual service.

Considering the difficulty of building a multi-tenant application, there is no reason to put that much effort into making an application multi-tenant. A better option is to create a virtual appliance. It is simpler to manage, maintain, and secure such an appliance.


For instance, these are the appliances provides. All free and easy to use. And, there is no need for these applications to be multi-tenant. If you need to support one more client, just fire up one more virtual appliance. (An appliance is a virtual server, that is stripped down to minimal installation so that all it does well is just run that application). A simple virtual appliance can range from 20 MB(!) to 250 MB.

Summary: Don’t worry about multi-tenancy, unless you are building a blazingly fast or performance oriented, or special purpose software like an enterprise database. Otherwise, you are best served by a virtual appliance. This is the trend and get with it!

 Posted by at 11:46 pm

  One Response to “Fallacy of Multi-tenancy”

  1. Being able to support Multiple customers exclusively vs providing core functionality which works across multiple customers is the part where people confuse multi-tenancy. The biggest fallacy in programming, years ago was hard-wiring service names/ports/URL’s which today have become virtual and configurable anyways. The question then comes down to licensing- If I have license for 1 Oracle Database do I benefit from firing up several instances for different customers or can I optimize? I think with newer technologies/trends even these concerns do get addressed. Finally is it cheaper to maintain one instance of my application vs several virtual instances of my application is another consideration that makes this choice even more interesting. End of the day, people make multi-tenancy a big deal.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>