I’ve recently been having some conversations with clients who currently provide an on premise software solution. Their product started out as a two-tier thick client and has moved towards a cloud-hosted N-tier web application. Currently they deploy their solution on premise for each of their customers. They think they need to become multi-tenant in order to stay competitive but I’d argue that they already are multi-tenant and their stated goals of lowering infrastructure and operational costs are really impacted by two key things: tenant isolation and infrastructure density.

The term multi-tenancy gets thrown around a lot these days but what do we really mean when we say this?

Like most new buzz word being thrown around, it’s almost like the zen-like state of oneness when you get yourself some [SOA, Agile, DevOps, Insert-Buzz-Word-Here]. You don’t know if you’re there until you’re there.

So how does one achieve multi-tenancy? What does it really mean—from an architectural and operational perspective? Is there only one path?

“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.” –The Wikipedia

Thanks Wikipedia but I would take issue with the clauses “single instance” and “runs on a server”. In reality, there can be any number of instances and servers where the same software can run to support multiple tenants. Any multi-regional application is going to have instances in the regions that it services and some form of network load balancer that routes traffic to the appropriate instance through some means. Does that make it any less multi-tenant? I think not.

If I take my software and install it on multiple servers then allow multiple disparate user groups to access that software from any of the servers, is that multi-tenant? I would say yes. In most people’s minds, this is quintessential multi-tenancy.

If I take my software and install it on multiple servers, then isolate those user groups so that each group can only access the software from a designated set of servers, is that multi-tenant? I would still say yes. However, this is considered to be quintessentially ‘single-tenant’.

In both cases, my software is supporting multiple groups of users who share common access with specific privileges to the software instance”. What’s the difference? Physical isolation of network traffic. What’s the outcome? Well, in the scenario where I allow all tenants to utilize any of the servers I get an extremely high density environment. Inversely, when I restrict access to tenants to a dedicated set of servers I get an extremely low density environment. One has a very low cost per user and a much smaller infrastructure scale vector (how many new servers are needed per new tenant). You might be saying, ‘But wait, that’s not multi-tenancy, that’s a single tenant solution!’

My response? Multi-tenancy is not about where you draw the line in your system to isolate your tenants. Some draw that line around the application and database tier, some just around the data tier. In doing so, we are creating duplicative instances of those elements of the architecture for each tenant. Does that mean the web tier is multi-tenant but the data tier is single tenant? No, it’s still a multi-tenant solution, it’s just a question of how tenants are isolated within the system. Some draw that line around their entire architecture and create isolated silos of their entire software instance and infrastructure for each tenant. Consequently a really expensive path to take but if you want to isolate your user groups completely it can still be desirable.

My point is, we spend a lot of time exerting effort under the banner of ‘multi-tenancy’ when the problems we’re really trying to solve are related to key decisions around tenant isolation and the outcomes we desire have more to do with achieving a higher density infrastructure. So let’s spend less time worrying about the proverbial holy grail of ‘multi-tenancy’ and more time thinking about the real architectural problems we face: tenant isolation and infrastructure density.