Multitenancy: How to Grow a Line of Independent Products from a Single App

SaaS products need multitenancy most of all, but they are not the only ones. This approach is applied wherever a company simultaneously supports multiple versions of the same product.

Image

For example:

• One business sector of a company sells services to private clients, while another works with legal entities. In both cases, the employees use the same sales system, but they need different features.
• The organization purchases a third-party company, and it needs to be connected to an application with which all the employees of the enterprise will work. However, the data of the two sectors must be processed independently, and there have to be independent namespaces.
• The company creates different versions of the same product, that are designed for different groups of users. The core of the solution remains the same, but the features change depending on what customers need.

Without multitenancy, developers have to embed switches and feature limiters in the code, configure access policies, make sure that data does not overlap, and manually manage access to resources. When launching each new feature, you need to think carefully about who should work with it, and how to restrict access at the architectural level for those who do not need it.

In a multitenant application, you can enable or disable features for different user groups, and configure access levels and data handling rules at the supply level. Even if a product has five versions, they can all be managed by a single development team.

Multitenancy provides business users with process independence

Data from each business module is sent to a dedicated environment. Processes within the product are organized in such a way that different tenants do not interfere with each other:

• The microservice architecture allows you to allocate resources for different processes and distribute them among users.
• The metadata and recipient context services process the data of each individual business customer, allowing everyone to create their own entities for their definitions of users, data source systems, and necessary actions.
• ID keys are used to distribute data flows between different users and within their native IT-ecosystem.

All of this allows a multitenant product to differentiate data and processes both at the level of individual customers and at the level of end users.

Possible architecture options for multi-tenant applications:

1. A single pool of resources, a single data store, with one installation, and separation at the software level.

Such an app understands on its own where to put the different kinds of users, and what features they will need. This scenario ensures optimal resource utilization, easy administration and software development. This is multitenancy at the core level. This is the way to go if you are creating a multitenant app from scratch.

2. A single data store, with one software installation, where resource pools are tenant-specific.

In this case, the division between tenants occurs at the infrastructure level. Each group of users accesses its own URL, or connects to its own server.

Resources are used less economically, but each tenant has a guaranteed capacity, as they can use their own pools. Architecturally, this approach is simpler than the first option, and if your company has its own data storage and processing center, it may actually be the optimal one.

3. Each tenant has their own software installation, resource pool, and data store.

This is the least cost-effective option. It requires the most support resources. Essentially, each tenant gets their own copy of the app. Therefore, developers need to work on each version separately, and their support is built independently. If the company needs to control the situation as a whole, it is necessary to build an integration solution.

This scenario is suitable for applications that were developed without multitenant usage in mind. This is not multitenancy in the full sense of the word. Rather, it is a way to achieve some of its features when redoing the product seems too expensive or impractical, for any reason.

What you need to make a multitenant product

Multitenancy is built at the architecture level, so in an ideal situation, you need to think about such features from the very first steps of working on an application.

The development of multitenant products is based on the Feature-driven Development (Trunk-based Development) principle. Developers create new features that can be enabled and disabled for different user groups.

We recommend starting the path to multitenancy with the transition to Trunk-based Development. This allows developers to look at the product as a set of features that can be used to create parallel versions.