Multi-tenant
Application
Multi-tenancy is
an architecture in which a single instance of a software application runs on a server and serves multiple customers. Each customer is
called a tenant.
Multi-tenancy
can be economical because software development and maintenance costs are
shared. It can be contrasted with single-tenancy, an architecture in which each
customer has their own software instance and may be given access to code. With
a multi-tenancy architecture, the provider only has to make updates once. With single-tenancy
architecture, the provider has to touch multiple instances of the software in
order to make updates.
 |
| Figure 1: Multi-tenant Architecture |
 |
| Figure 2 : Detail overview of multi-tenant application architecture |
A multi-tenant application needs to be carefully
designed in order to avoid major problems. It:
- needs to detect the client (or tenant) that
any individual web request is for;
- must separate persistent data for each tenant
and its users;
- has to segregate configuration for each
tenant;
- cannot allow cached data (e.g. views)
to leak between tenants;
- requires separate background tasks for each
tenant;
- must
identify to which tenant each line of log output belongs.
 |
| Figure 3 : Single-tenant and multi-tenant application |
Advantages
of Multi-tenant application
1. REDUCED MAINTENANCE COSTS
A multi-tenant
application is a single codebase, installed in a single location (a single
server or pool of servers), and potentially relying on a single instance of
each backing service (cache, database, log, etc.). When an end-user reports an
error, developers don't need to determine first on which instance the error occurred before replicating and debugging. A single source of
application logs helps here, too. And when a fix is ready, it gets committed
into the (only) repository, and re-deployed to the (only) server/pool – so all
tenants benefit from the fix immediately and simultaneously.
2. NCREASED SCALABILITY
Imagine a situation where an application is set up for two clients, and
each client generates about 1.5 server's worth of load. If the application is
deployed separately for each client, it takes four servers (two each) to handle
the total load. On the other hand, a multi-tenant application could be
installed on just three instances to handle the same load. With more tenants,
the advantages of a multi-tenant architecture grow even further.
Disadvantages
of Multi-tenant application
1.
INCREASED COMPLEXITY
A single-tenant application is simpler than the equivalent multi-tenant
app. There doesn't need to be any code to protect against data leakage between
tenants, or to detect which tenant a web request is intended for. Its
configuration can be essentially static. With a separate instance of the
application for each client, logs are segregated, so the log format can be
simpler.
2.
REDUCED DISTRIBUTION OF RISK
By running on a single server (or pool), backed by a single database, a
multi-tenant app has fewer points of failure – but those failure points have a
greater effect. When a single-tenant application instance breaks (say, the
database goes down), it brings down a single tenant; other instances are able
to continue unaffected. When the database for a multi-tenant app is
unavailable, all tenants experience loss of service.
3.
REDUCED FLEXIBILITY ACROSS TENANTS
A single-tenant, multi-instance app has greater flexibility to set
low-level configurations (of the server hardware or OS, or of the web server,
or the application itself) than a multi-tenant app. This won't be a problem for
many applications, but if the application needs a high degree of customization
for each new tenant, a multi-tenant app might not be the best solution.
