In software, specifically B2B/enterprise software and SaaS, multitenancy is an architectural pattern in which the data of all of the 'tenants' (or customers/users) of an application lives in the same 'instance' of the application. This is in direct contrast to a single-tenant architecture where each tenant's data lives in its own instance of the application, typically on completely seperate hardware.
Multitenancy doesn't necessarily imply that tenants share data though, just that they share underlying application resources. Prior to the maturation of the Internet and more recently the Cloud, enterprise software vendors would deliver their software applications directly to customers for installation and deployment within their own data centers and infrastructure. As such, software was inherently single-tenant. But over the past 10-15 years, the advent of cloud computing and SaaS have led to enterprises ditching their own data centers and infrastructure in favor of vendor-managed, multi-tenant software. In most cases today, cloud-based multi-tenant architectures are preferred by both vendors and users.
There are quite a few benefits to multi-tenant architecture, for both users and vendors. Here are just a few:
Multitenant applications are generally cheaper to build and maintain over the long run. It's much cheaper to scale out one set of infrastructure (ex. database, app servers etc) to efficiently support all of your customers vs. having to deploy a separate stack (with dedicated hardware) for each of your customers.
Aside from lower hardware and infrastructure costs, multitenant applications are easier to upgrade and patch since all customers use the same version of the application. This means a lot less hours spent upgrading and supporting individual customer instances, which in turn means a lot less $$ spent on expensive support and maintenance.
In multitenant applications, all tenants are on the same release schedule and so receive new features and updates simultaneously. This makes it easier for vendors to release new updates as well as align on marketing and communications efforts. And even in cases where tenants shouldn't receive new functionality, the advent of feature flagging systems has made it easy to control access via software rather than infrastructure.
As with any other architectural choice, multitenancy doesn't come without its share of tradeoffs:
In single-tenant applications, data isolation is a feature of the architecture and deployment. Since each customer has its own instance of the application, there is no risk of the application accidentally exposing data across tenants. As a result, the application layer is free from the burden of having to validate access or 'contextualize' its database queries to a respective tenant's data. However, in a multi-tenant architecture, the risk of introducing a bad db query that exposes data across tenants is very real since all data resides in the same database. This means that security becomes an application-level concern and thus a concern that all application developers must be mindful of when writing and testing their code.
While having all customers on the same instance of the application makes for easy upgrades and patches, the downside is that your infrastructure now becomes a single point of failure. Whereas an app server going down in one instance of a single-tenant application would only affect one tenant, an app server going down in a multitenant system can cause outages for all tenants. As a result, redundancy and resiliency are of utmost concern in any multitenant application.
Despite the recent rise of SaaS and cloud-based enterprise software, some industries, particularly those under tight regulations (ex. financial, national security, utilities) are unable to use multitenant applications, primarily due to the security and reliability concerns mentioned above. Software vendors working with these types of companies and organizations will often end up having to deploy separate, single-tenant versions of their applications specifically for these customers.
It's clear that when it comes to SaaS and enterprise software, multitenant architecture is the defacto standard these days. Given the pros and cons above, here are a few recommended best practices:
It's much easier to deploy a multitenant-aware application into a single-tenant environment than it is to make an existing single-tenant application multitenant. As such, modern applications should be built as multitenant by default. This means ensuring that your application and all entities within your data model are 'tenant-aware'.
In addition to being 'tenant-aware', your application should enforce proper access controls to ensure that tenants can only read and write their own data. The best and easiest way to do this is to handle tenancy at the highest level and scope the entire application by tenant, disallowing any cross-tenant reads or writes throughout your stack.
Sounds like an oxymoron right? But it isn't. Modern data residency laws like GDPR require data to be partitioned by locale. In practice, this can mean that you may need separate instances of your already-multitenant application. For example, you might need one cluster or instance for European customers and another instance for everyone else. Making sure your application design allows for this upfront will save a lot of time and effort in the future.