Many clients – one system: multi-tenant architecture in software projects

Contents

The trend towards Software-as-a-Service (SaaS) poses new challenges for providers of software applications. How can an application be operated cost-effectively for a growing number of customers and at the same time meet their requirements in terms of performance, security and customizability?

Kai Weingärtner

Kai Weingärtner is a Solution Architect at Opitz Consulting Germany. His focus is on cloud architectures and DevOps.

A cleverly chosen multi-tenant architecture creates the necessary structures. The tenants share an application with other tenants, all of which are isolated from each other so that the application behaves like a dedicated one for the individual client. A tenant usually comprises a group of users, but can also be a single user. In a B2B context, it is often a company, while in a B2C environment it can also be a single user.

A typical driver for the introduction of multi-tenancy is the move from installed software to a software-as-a-service business model. In contrast to per-customer installed software or managed service offerings, a multi-tenant application is developed and operated as a single product.

The added value lies in the reduced maintenance and operating costs when one version works for many customers. In addition, the costs for the infrastructure are distributed among the customers. However, the challenge lies in not allowing the complexity of multi-tenant operation to affect service development while at the same time meeting the requirements in terms of data and performance isolation as well as infrastructure and operating efficiency.

Preliminary considerations – Requirements and customer wishes

There are several questions that architects should clarify at an early stage, as they have a significant influence on the design. It is important to know which customers the application is intended to address and what their requirements are. In certain industries, there are also regulatory requirements. If customers want a dedicated infrastructure or have specific performance expectations, the architects must carefully examine which resources they can separate or share.

The number of clients and data volumes also play a major role. Can the tenants share a common data schema in terms of performance? Will the provider resources reach a limit if each tenant receives a separate database instance? Is the manually supported onboarding process sufficient or does it need to be fully automated?

The planned billing model can also influence the architecture, particularly in terms of monitoring. A monthly flat rate with a request quota requires different metrics than a calculation based on the number of users.

Finally, planners should also roughly define the need for customizing: If the customer expects customized styling, that is part of the tenant configuration. How flexible does the application need to be when integrating third-party systems, for example a customer's own identity provider? A clear target image helps to set the right course here.

Silos, pools and everything in between

Multi-tenancy does not necessarily mean that the clients share all application resources and the entire infrastructure, but simply that the overall application is presented as a single product. The following models are therefore in use: the silo model, the pool model and hybrid forms of both, such as the bridge model (see Figure 1).

The silo model assigns a dedicated infrastructure to each tenant, for example a database instance or a separate VM for the application logic. Even if the infrastructure is not particularly cost-efficient here, this approach has some advantages: Infrastructure costs can be easily allocated to each client and data isolation is automatic. Local developers treat the application as a single-tenant application. This results in a simpler migration path for existing applications launched as classic single-tenant products.

One disadvantage, apart from the costs, is that admins have to provision infrastructure when onboarding tenants. This means that provisioning must be automated to avoid uncontrolled growth. Deploying updates also takes more time here, but allows successive rolling updates and canary releases.

In the pool model, all or several clients share one infrastructure. Tenant isolation takes place in the code, while the shared use of the infrastructure minimizes costs and speeds up deployments. However, you have to deal with the noisy neighbor problem, where one tenant uses so many resources that it affects others. Performance isolation should therefore be used for customers who expect guaranteed performance. It is also necessary to check whether the resources of a database instance, for example, are reaching their scaling limits.

A combination of silo and pool models often makes sense, for example a pool in the service layer and a silo in the database layer, which combines high data isolation with cost savings. This model is also known as the bridge model. In a microservices architecture, individual services can also differ in the model if, for example, a silo model is only necessary for services with high isolation requirements (such as payment data).

The choice of model is based on many factors and has far-reaching implications for implementation. Provided none of the factors mentioned speak against it, the pool model is the first choice due to its efficiency.

The control plane and its tasks

When designing a multi-tenant architecture, aspects such as data isolation or the scaling of services are typically the first things that come to mind. However, there are also numerous tasks relating to the lifecycle and operation of the clients, which the administrators have to manage in a standardized and centralized manner, regardless of the specialist area.

These tasks should be mapped by a control plane that works in parallel with the application (also known as the data or application plane in this context) (see Tod Golding: Building Multi-Tenant Saas Architectures; 2024). The more the number of tenants grows, the more important the control plane becomes to ensure central management of the clients (see Figure 2).

Another function of the control plane is the onboarding of tenants. This generates metadata such as a tenant identifier, which allows requests to be routed correctly. In the case of a silo database, further metadata would be added, such as the connection parameters to the database. The specific infrastructure and configuration are then provisioned. In the case of automation, this builds a new database in the silo model and creates a new user pool for user identities, i.e. individual users within a tenant. An early, uniformly automated onboarding process makes sense, as otherwise the maintenance effort increases in the medium term and runs counter to the added value of multi-tenancy.

User identities are relevant for the control plane insofar as it uses them to establish the tenant relationship and can therefore make tenant metadata available to the application plane.

A billing component of the control plane manages the billing plans of the customers and, if required, obtains usage statistics of the clients from the metrics component. Metrics and log aggregation are also important for client-specific usage and error analyses. To this end, the Application Plane services always provide a tenant ID for identification in logs and metrics.

iX Special Issue Software Architecture

This article can also be found in the iX/Developer special issue, which is aimed at software architects. In addition to the classic architecture content on methods and patterns, there are articles on socio-technical systems, quality assurance and architecture and society. Domain-driven design is also a topic, as are team topologies and security.

We have been able to attract well-known experts as authors, who pass on their knowledge in many exciting articles – such as this one – for both architecture beginners and specialists.