Multi-tenancy...as opposed to what?

Question

In the last several years I keep hearing the term multi-tenancy being thrown around, and each time I Google its meaning it leaves me confused:

(Wikipedia) : The term "software multitenancy" refers to a software architecture in which a single instance of software runs on a server and serves multiple tenants. A tenant is a group of users who share a common access with specific privileges to the software instance.

Right. But isn't that already what a server is?!? Software serving multiple clients?!? If I have a VM (or physical server) and start running a web server (httpd, Tomcat, etc.), and that web server starts serving requests for multiple HTTP clients, wouldn't that be a multi-tenant web server? And if I stand up a MySQL database, and that DB starts serving requests for multiple clients, wouldn't that be a multi-tenant DB?!?

I guess I don't see the need to distinguish any server as being multi-tenant...isn't that what servers are already meant to do (serve multiple clients)?

So I ask: if multi-tenancy is "[an] architecture in which a single instance of software runs on a server and serves multiple tenants"...then what is its alternative?

Or, put differently, how could a server (web server, DB, etc.) not be multi-tenant?!?

Answer 1

I think your confusion is between the technical term "client" (as in client-server) and the business term "client" (as in, a paying customer). Multi-tenancy usually implies a server serving multiple business clients, each with their own separated environment, using shared hardware and software.

For instance, I have several Wordpress blogs running on a single server instance - there's just one WP process running, just one deployment, but several blogs defined, each with its own segregated data store (in this case, set of database tables, a common multi-tenancy technique), so that each blog owner can only manage their own sites, not knowing or caring that it's technically sharing resources and files with other blogs. This is an example of a (simple) multi-tenant service.

The technical challenges of multi-tenancy include security (how to make sure one tenant can't see another's data, a big no-no), reliability and robustness (how to prevent one tenant's bugs or plugins from taking down the others, or how to take one tenant offline or backup their data without affecting the others), scalability (how to support a large and dynamic number of tenants without having to migrate the entire server to new hardware when more are added) and provisioning (how to manage, extend, disable and add new tenants without taking down the system).

Answer 2

Suppose you are a software business and you develop a custom web application for a customer. You run it on a server for them, and every now and then they order some changes.

Then you get another customer, they also want your application! With some changes -- their own logos and so on, and of course with different data so running on a separate database. So you tweak your application and install this version on a second server.

The more customers you have, the more it becomes hard to control.

Eventually you want to move to one application, with one installation, maybe using one database, but where the different users can still only absolutely see their own data. That's a multi-tenant version of your application.

Of course had you started out with the idea that you were creating a product for many customers, you'd probably have designed your web application like that from the start. But it happens a lot that something starts out as custom software for one customer and only later evolves into something bigger, so then going from "single-tenant" to "multi-tenant" becomes a big thing.

Answer 3

The important part is "a tenant is a group of users who share a common access with specific privileges to the software instance."

Let's put this into an example of Stack Exchange. There are four primary classes of users - unregistered users, users, moderators, and staff. There are also over 160 sites in the network, and a user may have a different permission set on different sites - staff is likely to be staff everywhere, but I'm a moderator here on Software Engineering, a user on Stack Overflow, and I'm not registered on a handful of sites.

In a multi-tenant instance, all sites would share the same resources - the same web servers, the same file directories, the same databases, and so on. Then, there would be detection to determine what I have access to and what that level of access is. For example, the subdomain may be used to load my access level from credentials. All of my user records are stored in the same database, but the subdomain may be a key to load my permissions and my settings.

In a single-tenant instance, all sites would have different resources. They may share a common code base. They may share the same physical resources, but may have multiple databases or directory structures. There's no intermingling of the data. In my Stack Exchange example, you may deploy the same codebase to 160 web root directories and update 160 database schemas when you deploy new code.