Talk about the multi-tenant design of a SaaS platform

#头条创作挑战赛 #

preface

I experienced a company's SaaS system with a few technical colleagues, from the operation platform, to the tenant authorization platform to the business application, all the way to the configuration to the application steps are quite cumbersome, so that the technical colleagues do not understand why it is so complicated. It turned out that they had little understanding of the multi-tenant design of the SaaS platform, and found it difficult to understand such a design due to the lack of conceptual support. For product managers who are new to SaaS platforms, it is estimated that there are many things they don't understand, and this article will talk about the multi-tenant design of SaaS platforms.

Take DingTalk as an example to see the actual multi-tenant scenario

Before talking about design, let's take DingTalk as an example to see how a SaaS platform works. I believe that most B-side product managers have experienced DingTalk, and we talk about the process of DingTalk's tenant registration to use in two dimensions. One is to look at the process of using DingTalk from a personal perspective, and the following figure is the process of personal use of DingTalk. This process omits the function of personal registration and chat with other people and friends, which is actually not a B-side business category.

The key here is that if you want to use features under an enterprise (or team, hereinafter collectively referred to as tenants), you first need to be invited to join a tenant. Also, an account can be invited to join multiple tenants. If you belong to multiple tenants, you need to switch to the tenant before you can use the operations related to a tenant. For example, our workbench, cloud disk, these are related to tenants, the following diagram is DingTalk's workbench, there will be a tenant by default, you can switch tenants by pull-down.

So what does it look like from a tenant perspective? The process is shown in the following figure.

Unlike individuals, for tenants, there are several additional steps to create teams, enterprise certifications, and invite members. This is a feature that falls under the administrator category, where enterprise certification is not required, but more features and resources are available to certified enterprises.

Through the example of DingTalk, we will get the following entity relationship:

• A platform has many tenants;
• A platform also has many users;
• A user belongs to multiple tenants, and a tenant has many users.

This is a fundamental relationship, and it is important to understand. So in fact, the general SaaS platform will have three backends:

• Operation management background: that is, the background system of platform operation management, which is usually used to manage tenants, mainly the permissions of tenants and the allocation management of resources; This platform is not accessible to us as SaaS users, but it is essential as SaaS product design.
• Tenant management background: that is, the management background used by the tenant, which is mainly used by the administrator of the tenant to manage members and assign the permissions and resources of internal members of the tenant.
• Business applications: that is, the business systems used by each member of the actual tenant, such as the desktop and apps of DingTalk that we usually use, are actually business applications. There are actually multiple business applications. For example, DingTalk's built-in OA approval, attendance system, intelligent form filling, etc., are actually business applications. Some designs are designed to simplify by merging the tenant management back office and business applications into one back office on the back office system.

The team version of DingTalk is free to experience, so if you are interested, you can create a team to learn about the functions of the tenant management background.

Tenant permissions and resource management

For a platform, the tenant is the primary object of its services and the ultimate buyer, the subscriber of the SaaS system. Therefore, one of the core functions of the SaaS operations management background is to manage the permissions and resource management of tenants on the management platform. The management of permissions and the subscription model of the SaaS platform have a relatively large relationship, and can also be considered a resource from an abstract point of view. Our common SaaS has two ways to do this:

• Subscribe by sales version: This different edition will have different features. Generally, the business application used for the platform itself is a single application, that is, permissions are within the application, and different functions are assigned according to the version subscribed by the tenant.
• Per-application subscription: This is a relatively large platform, the platform will have several applications, and the tenant first chooses to activate some applications in the platform. Of course, the sales version can be subdivided into the app, and DingTalk is actually this model. This model is heavier, but the scalability will be better, suitable for SaaS products that are interested in building open application platforms.

The structure of the two models is compared in the following two figures, of course, the multi-application SaaS platform can also be separated into a separate layer of sales version for each application.

Resources are divided into two categories, one is platform-level resources and the other is in-app resources. Platform-level resources are managed by the platform, such as the capacity of DingTalk, the usage period of applications, etc. In-app resources refer to the resources of each application itself, such as the number of authorized accounts (of course, some at the platform level will also have a limit on the total number of accounts), the number of text messages, etc. The principle of this resource management is who maintains who manages, that is, the resources maintained by the platform are managed by the platform, and the resources maintained by the application are managed by the application, and the following is a relationship structure diagram of resources. Generally speaking, resources will need to be purchased by tenants, or the platform will regularly distribute free resources (for example, DingTalk's "SMS Ding" means that there is a free quota that can be used on a monthly basis).

Menu management

Since different sales versions are involved, there will be menu management, that is, the menu needs to be managed uniformly, and then the menu is combined into a sales version, and finally authorized according to the version purchased by the tenant, and finally the menu is available to the customer. There is also a question of whether the menu is managed by the platform or the application. Both models actually exist in reality. The platform we encountered is platform unified management, that is, the application must first be in the platform configuration menu so that tenants can use it. Personally, this method of unified management by the platform is not recommended. On the one hand, it leads to strong coupling between the platform and the application, if the platform has a third-party application, it means that the third party needs to synchronize the menu with the platform; On the other hand, it limits the flexibility of the platform, because since it is a menu, it is necessary to have a standard menu management model to manage it uniformly, which requires that the application must follow the rules of the platform. Another is that the platform has to open the account management menu to application developers (or operators), which actually adds complexity.

In fact, the application developer will also have a corresponding operation team, and the platform only needs to provide a communication channel for tenants and application developers. For example, after a tenant subscribes to an application, notify the application developer to maintain the tenant's permissions in a timely manner. Because, the actual B-end enterprise subscribes to an application, there will be an order payment process, and the general payment is by remittance (when we purchase a third-party application on DingTalk, we also pay to the third party separately, rather than through channels such as Alipay), which means that the service will be intervened after the payment is successful. Of course, there are also free trial periods, at this time, as long as the tenant subscribes to the application, the after-sales team of the application developer can intervene in advance to provide services, in fact, it can also be connected after subsequent payment.

With menu management, the entity relationships of SaaS become the following, where resources are omitted, and the actual resources and sales versions are somewhat similar, except that there will be platform-level and in-app resources. In summary, the relationships between the entities are as follows:

• There will be multiple applications for a platform;
• An app will have multiple menus, which can be combined into multiple sales versions through menus;
• Tenants belong to one platform, and tenants can subscribe to a sales version of an application on multiple platforms according to their needs.
• A tenant has multiple users, and a user can belong to multiple tenants, but a user belongs to the same platform.

Core points of multitenant design

With the overall concept above, we know the core points of the multitenant design of SaaS, organized as shown in the following diagram. Here are a few points:

• The difference between user and account: For the platform, the registered account is actually a platform user, and the uniqueness of the user should be determined by the user. At the same time, in order for users to be able to switch tenants, there needs to be user tenant management (that is, which tenants the user belongs to); For tenants, users are actually accounts, that is, which accounts are opened under my tenant, and generally one account corresponds to one employee. It should be noted that the account under the tenant can be cancelled (or disabled), for example, if the employee leaves, he can still use the platform, but cannot use the functions under the tenant.
• Order management: Platforms, apps, and tenants will all be able to see orders, but in different scopes. The platform manages the orders of the entire platform (excluding the orders of its own resources in the application, unless the platform covers the transaction link in the application), manages the orders generated by the application itself, and the tenant sees its own orders.
• Tenant permission management: If the platform is a pure platform, then in fact, there can be no permission management, but the general SaaS platform will not be an empty shelf, there will be one or more core gripper applications. This depends on the design of the platform, whether to treat their application as a third party at the beginning or special treatment. The permissions of the application management tenant are mainly the management of the sales version, which can be managed automatically through the automatic synchronization of orders. However, consider special scenarios, such as tenants may purchase a lower version, but in order to promote the premium version, the tenant may be given trial access to the premium version in the background.
• Tenant background: The tenant background and business applications can be mixed together, but the administrator's permissions are different. The tenant background is mainly to invite members (open accounts), conduct authorization management (usually have functional permissions and data permissions), and then manage the resources and orders consumed on the platform, mainly purchasing and viewing.
• Business applications: Generally, grassroots employees use more frequently, and for management more report functions. This is mainly to support users to switch tenants and facilitate members of tenants to use the business application functions opened by tenants.

Multi-tenant data storage design

There are technically three ways to store multi-tenant data, one is a common data table, that is, the data of different tenants is stored in the same data table, and then distinguished by tenant ID. This kind of SaaS application suitable for small scales has the advantage of simple development and implementation, but the disadvantage is that the operation data between different tenants will have a certain impact (because the operation of the same data table, if multiple tenants operate at the same time, there will be concurrent performance problems).

The other is the table splitting design, that is, different tenants have the same data table structure, but use their own data tables. For example, if the name of a permission table is auth, then tenant A is called a_auth, and tenant B is called b_auth. This design requires the dynamic creation of tables based on tenants, and general table names will have tenant IDs to distinguish uniqueness. The degree of isolation is much better than shared tables, and the complexity is higher, and because the database is shared, the overall performance will be affected by the database performance, that is, the operations between tenants will still affect each other to a certain extent.

The last is the database splitting design, where different tenants use different databases, so that the data is completely isolated. Of course, the technical implementation is also the most complicated. For vertical SaaS applications where business systems are heavy, it is recommended to design them in this way. Because SaaS systems that go deep into the customer's business are generally high-frequency operations, as the number of customers increases, if the data is not separated, it will lead to performance bottlenecks.

Of course, in fact, you can also use a progressive data storage design, that is, use a common data table when there are fewer customers, use a table sub-table design when there are slightly more customers, and finally use a shard design. This upfront cost is low, and there will be data migration costs later.

summary

This article sorts out the structure of the multi-tenant design of the SaaS system and the characteristics of various designs, which I believe will be of great help to SaaS product managers. For the design of SaaS system, if you want to investigate complex SaaS systems, it is recommended that you can experience Alibaba Cloud background and DingTalk, in contrast, although the background of cloud vendors is not very similar to SaaS, but the basic design ideas are the same, and the design of cloud vendors is more complex, covering multiple business subsystems and multiple types of resource allocation.