Multi-Tenancy Still Doesn’t Matter

Three years ago, I wrote a blog entitled, “Does multi-tenancy really matter anymore?” As three years have passed and the conversation is still being had by some in the industry, it seemed like a good time to revisit the topic and share my thoughts on why multi-tenancy still doesn’t matter. 

Definitions

I would like to start by defining some terms, abbreviations, and acronyms that I refer to in this post. The purpose of the definition section is purely to help the reader’s understanding, and not to appear patronizing. I apologize upfront if it is interpreted as such.

Multi-Tenancy (MT)

MT is 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. In short, it means that the software handles any request from any user from any tenant. It does not require more than one in-memory instance of the binary code to serve the incoming requests regardless of the tenant. In contrast, a non-MT software artifact requires an in-memory instance of the binary artifact per tenant. Note though, that the non-MT artifact running in-memory can be sourced from the same physical binary being stored on disk, as long as it is loaded into separate memory spaces.

Cloud-Based Applications (CBA)

Any application, regardless of architecture, executing in a cloud rather than on owned computers. Basically, it means that the application executes on someone else’s computer.

Software-as-a-Service (SaaS)

SaaS is, at the core, a software licensing and delivery model. Rather than paying a perpetual fee upon procuring the software, customers pay a recurring – often monthly – fee for the right to use the software. SaaS does not bear any indication to the architecture of the software licensed. Although, the typical expectation when referring to SaaS is an MT architecture served to the end users by means of a browser. However, at the core, SaaS is a licensing and delivery model and not a software architecture definition.

Multi-Tenant Cloud (MTC)

MTC is a little harder to find a conclusive definition for. Hence, this is my interpretation of MTC. MTC is the ability to execute identical binaries on the same instance, but each in their own memory space.

Common Topics

Let me start out by stating, that I, as a software architect responsible for constructing cloud applications for massive scale, favor MT as an architectural construct when it comes to net new development and especially when we are talking about a microservice-driven architecture. This blog is not about defending non-MT, but to look at different statements on the advantages of an MT architecture where these advantages is not necessarily a function of the architecture but rather a function of a chosen business model.

One Version

What I see often is the tendency to liken one version of a given solution with MT. In reality, there is no correlation between the number of versions a software vendor maintains and MT. Designing your software to be MT has no impact on how to manage your source code and the number of versions you have of your application. It is completely feasible to have multiple versions of MT applications and to deploy different versions using modern CI/CD tooling, like VSTS. The reality is that most vendors of MT applications do this to be able to update customers in batches, depending on the geo-location of the customers.

Maintainability

In this case, maintainability refers to the upgrade and operational responsibility of the software utilized by customers. The ability to outsource operational responsibility in all its facets is nothing new – it actually dates back to the 1960s and 1970s although at that time it went by the name of service bureaus, coined Application Service Provider (ASP) in 1996. The point being that the ability of companies to outsource maintenance far precedes the emergence of MT as a software architecture, as the earliest references found on the topic date back to 2003.

Shorter Upgrade Cycles

I believe there is a misperception that an MT application allows vendors to upgrade their solutions more frequently than non-MT applications. Upgrading a running system is not about the architecture. It’s a function of how well the deployment automation works, and more importantly, how many distinct versions of the software need to be upgraded; the number of distinct instances needing new binaries; and last but not least, if there are any breaking changes.

Single-Deployment Scenario

There is no direct link between an MT architected application and the number of deployment scenarios either, where deployment scenarios refer to discrete ways the software is distributed. It is true that the operational impact increases as a function of the number of deployment scenarios. Having to deploy software in both cloud and on-premises will lead to increased operational costs; nevertheless, both MT and non-MT architected solutions can be deployed in various ways – depending on the business requirements or need.

Operational Efficiency

The argument on operational efficiency goes that an MT application is easier to operate. This is an interesting argument that was true back in mid-2000; however, today, not so much. As written in my original blog on the topic, then the emergence of cheap infrastructure, automatic scaling capabilities, and improved deployment technologies undermine any business justification for re-factoring existing single-tenant solutions into multi-tenant.

In my view, the single most important driver for operational efficiency does not come from the architecture of the software but is a direct consequence of the combination of versions and deployment scenarios, as they are complexity multipliers. Bringing one or both of them down will increase operational efficiency, by providing innovations, quicker deployment and the actual costs of deploying.

Final Thoughts

My view is that multi-tenancy was and still is a red herring. There is too much focus on vendor side details and lack of focus on customer benefits. A multitenant solution can be expensive, unreliable, lack privacy controls, and not deliver functional capabilities that help me innovate my business when needed. Same can be said for single tenant. Tenancy does not matter to me as a customer. In my view, enterprise software vendors are better off investing in new functionality focusing on solving customer needs like better extension technologies ensuring that any customer enhancement does not break between upgrades; providing user experiences based on the tasks users need to do; and importantly, provide the required architecture for opening up enterprise software such that companies can embrace digital transformation.

So, multi-tenancy still doesn’t matter – what matters is the software’s ability to solve customers’ requirements in an efficient and user-friendly manner without causing unnecessary frustration.