When several clients or tenants share a single instance of an application (with the associated hardware and database), this is referred to as multi-tenant or multi-tenancy.
The data of the individual tenants is isolated from each other and not visible to the other tenants. Only the associated users have access. Each user typically has their own access rights, data and configuration details, allowing them, for example, to customize the appearance of the user interface.
This makes multi-tenancy the next evolutionary step for cloud services. In the past, a separate application ran on separate hardware. The cost of installation, operation and maintenance scaled almost linearly with the instances. However, this led to the following problems:
- The costs of updates, for example, was exactly the base costs multiplied by the number of instances. The more instances one had in operation, the more expensive everything became. With multi-tenancy, this is usually only determined by the number of “clusters”, which is often only a fraction of the number of instances.
- To put it simply, each instance in the traditional approaches has its own physical server. However, if this is only utilized at 90% capacity for 1 hour per day and at a maximum of 5% for the rest of the day, the hardware is being used very inefficiently. If, on the other hand, the hardware is overloaded, it is usually difficult to scale horizontally because this means adding new hardware in a timely manner. On the other hand, keeping buffer capacity is also very expensive, since this has to scale with the number of instances. For multi-tenancy, 10% of the total capacity is usually kept as a buffer. In addition, a mean utilization can be created as a base capacity. The bottom line is that these installations scale much more effectively and therfore offer the customer significantly lower costs (in some cases up to 5% compared to dedicated hardware variants) and can usually handle fluctuating load scenarios much more reliably.
There are three variants of multi-tenancy architectures, each with a different degree of complexity.
Variant 1: All tenants have a common database schema
This has relatively low costs due to the use of shared resources and is the simplest of the three variants. A single application and database instance is used to host multiple concurrent tenants and store data, allowing for easy scaling.
Variant 2: One application, multiple databases
This variant uses a single application instance with individual databases for each client, making this architecture more difficult to scale. It is often used when the database schema is uniform but the data requirements have to be defined individually. For example, international data that has different requirements depending on the geographical region.
Variant 3: Separate databases
The most complex variant in terms of administration and maintenance. Each user is given their own database, which means maximum flexibility and isolation of data between individual users.