Multitenancy was and still is a very popular and successful architectural pattern of the last decades. But, that is likely to change with the advent of cloud computing.
I remember well the time when hardware was expensive and uneasy to get. Waiting for weeks or even months to receive a new server I necessarily needed yesterday. Bothersome paperwork, awkward negotiations, hard-to-get approvals, and high costs. It was true pain to be avoided if possible. Multitenancy as an architectural pattern comes exactly from these circumstances.
The idea is pretty simple: deploy and operate a single system supporting multiple customers. The resources are shared, adding a new customer is quick and easy. But, of course, as everything in software architecture, multitenancy has several trade-offs. The biggest one is a lot of additional complexity. Tenant isolation must be ensured on every system level from configurations to data. This is not a simple task. The code must be aware of it on all layers, which makes even simple things pretty complicated with negative impact on performance. With increasing numbers of tenants scalability can easily become an issue as well.
Cloud computing as the enabler of DevOps, infrastructure automatization and containerization changed the traditional hardware provisioning. Nowadays, it is possible to spin up a new server, create a new database, or set up a new service bus within a second or even less. No more request tickets to an IT department! Hardware provisioning in the cloud became quick and easy, providing a solution for the problem multitenancy originally addressed.
Multi- vs Single-Tenancy
Compare a single multi-tenant system with multiple single-tenant systems:
In his book Cloud Strategy, Gregor Hohpe compares these two approaches to an apartment building vs. single-family homes. Such a mental model helps us understand the differences in the approaches.
It is definitely way simple to project a single-family house rather than a big apartment building. This is the main drawback of multi-tenant systems as multitenancy aspects leak deep into the structure and brings great complexity which slows development down and makes it more expensive and exhausting.
Building and Deployment
Having a construction plan and building material should mean no big difference in the building process. But, big apartment buildings tend to be unique and built ad hoc and unsystematic with project changes and adjustments during the construction work, while small family houses are uniform making them a perfect match for automatization of the building process. Automatization of everything is an important mindset-shift highly encouraged by the cloud services.
If you ever lived in an apartment house, you know how difficult and costly an accident can be. Old big buildings tend to resist change while small houses are easy to be rebuilt from the ground. Finding a bug, implementing a new feature, data migration, a design or functionality change, those activities are very hard in complex systems.
Efficiency and Scalability
While single-family houses can be built quickly and easily on demand, planning an apartment building must take into account the desired amount of tenants in advance: when the house is only half occupied it’s very inefficient to be run, the heating, elevator, lighting must still be taken care of and so on. Another trouble comes when the capacity is exceeded. Multi-tenant systems are based on vertical scaling with its well-known limitations. Even adopting horizontal scaling could be problematic with multi-tenant systems: Consider an extreme case where a feature is implemented as a serverless function (Function-as-a-Service). Because everything in a multi-tenant system is shared, constraints and limits are shared as well. A serverless function allows for example one thousand concurrent executions per second. With one hundred tenants accommodated in the system it makes theoretically only ten executions per second for a tenant, which could be just too little.
Operations and Management
It is probably easier to manage one building consisting one thousand apartments than to deal with one thousand small houses. To accommodate a tenant into an existing apartment will be always easier than to build a brand-new house for him. Depends on discipline and maturity of the automatization process. As the multiple single-tenant approach moves the multi-tenant complexity from development to operations, demands on the system administrators can grow. The key here is a good automatization of literally everything and adopting the DevOps mindset: divide the work among dev and ops people, bring them together and share the responsibility for the product within the team.
Cloud computing doesn’t mean the definite end of the multitenancy architectural pattern, but it does offer an alternative solution with a promise of reducing effort in development by shifting the complexity into operations. This is not thinkable without mature automatization and clean team responsibility.
But, there are valid use-cases for multitenancy as well as there are valid use-cases for computing outside the cloud.