After posting my introduction to multi-tenant applications last week, fellow Quick Lefter Bing Chou engaged QLer Bob Bonifield and I in a lively discussion about what really makes a multi-tenant application different from a single-tenant architecture.
We went back and forth, discussing clients, users, servers, domains, data segregation and more – so I think the right place to settle this debate is the Internet, with your help. Let’s go through some of the “definitions” that were fielded, and some various web applications from the real world, and see if we can determine what the real definition is.
Is it about having separate domains?
Wordpress.com lets users host a blog – and point their domain to the hosted blog, so that users can go to myblog.com instead of wordpress.com/myblog. Seems like a pretty good definition, right?
Nope … so is it separate userbases?
Harvest sets up a subdomain for each client (we have quickleft.harvestapp.com) and that client’s users log in to that domain, with a username and password combination specific to that client. So I log in to quickleft.harvestapp.com as john[@]quickleft.com, but that email won’t get me into any other domains. When I log into the app, I can only see projects and reports from Quick Left. Other apps with separate userbases – and no interaction between the data of various tenants – include SalesForce and BaseCamp. Feel free to leave some more examples in the comments!
But is this enough to define a multi-tenant application?
Maybe not …
Squarespace is a templated web hosting service. Customers set up a website and have their DNS point their domain to it. But Squarespace’s customers – unlike Harvest’s, for example – don’t have their own users; the sites hosted at Squarespace aren’t multi-user applications.
Can one application be multi-tenant and not?
What about Google Apps for Business? Here at Quick Left, we use Google Apps for email, calendar, and more. We don’t have a domain or subdomain point to Gmail, so to check our mail we go to gmail.com and type in our username (email address, really) and password. Gmail itself – the version that anybody can sign up for for free – certainly doesn’t seem to be multi-tenant, though it is multi-user. But on a business account there are some features that are tied to the business: we can share easily share contact lists and calendars within the organization, we have pages that only employees can access or edit, and so forth.
So what’s not multi-tenant?
In our discussion at Quick Left, someone asked if Twitter was multi-tenant. After all, it has a bunch of users, each with their own data, so why not? We don’t feel that Twitter is multi-tenant, on account of the lack of user groups (tenants) that segregate their own data. Likewise Facebook isn’t multi-tenant, or most social apps. And of course any application built and hosted for a single organization (like our own site) couldn’t be considered multi-tenant.
OK, enough beating around the bush. What’s the definition?
We don’t think there is a clear, concise definition. In broad strokes, y’know it when y’see it. You might say that the application is multi-tenant if the architects ever had to decide between deploying a number of separate (not pooled) instances of the app, or deploying a single instance.
Or you might say it has to do with data segregation: the idea that there are some datasets that simply shouldn’t touch, shouldn’t interact, and shouldn’t be viewable together in any combination. This seems to be the “definition” that most closely fits the examples we’ve come up with, and the spirit of the term (as we understand it).
Help us out!
What's your understanding of the term “multi-tenant application?” What’s an application that you’re not sure about, that you think we should discuss? Sound off in the comments below, and let’s figure this out together!