What is multi-tenancy?
Multi-tenancy is unique to the SaaS space. In SaaS services, a tenant is a customer who uses a SaaS system, and a tenant is different from a user, e.g., for a B-side SaaS product, the user may be an employee under a particular organization but the entire enterprise organization is a tenant of the SaaS system.
Multi-tenancy is a software architecture technique that enables multiple tenants to share a system instance and enables isolation of data and behavior between tenants.
Traditional Software Model VS SaaS Model
A traditional software project is generally defined as the development of a specific software system for a customer and its deployment in a separate environment, usually an on-premises environment.
The SaaS model, on the other hand, deploys software services to a cloud environment that can provide the same software services to different customers.
SaaS multi-tenant isolation model
For the SaaS model, multi-tenant resource isolation is a very basic ability, for cost and operational efficiency considerations, SaaS service providers need to build multi-tenant can access the software environment at the same time, different tenants access the same set of SaaS products and services, but the resource access needs to be strictly isolated.
SaaS resource isolation consists of several levels:
- The first layer is the isolation of resources such as compute, storage, and network involved in the underlying SaaS system.
- The second layer is the segregation of the system's basic data, which mainly includes organizations, users, roles, permissions, and product capability authorization relationships.
- The third layer is the isolation of all kinds of business dynamic data during the use of the system, such as business documents and operation records.
Multi-tenant architecture mainly addresses the first layer of isolation, i.e., the isolation of resources such as compute, storage, and network. In order to realize multi-tenant isolation architecture, we first need to figure out several common multi-tenant isolation patterns.
shaft isolation mode
Some SaaS providers choose the shaft isolation model, where each tenant runs in an isolated set of resources. Some may say, isn't this the traditional software model, and why would it be a SaaS model? But if these vertical wells have resources with standardized tenant identification, onboarding processes, billing systems, deployment processes, and operational processes, it's still a SaaS model over there, except that each customer has a set of end-to-end infrastructure.
dominance
- Meet strong isolation requirements: Some customers may put forward very strict isolation requirements for the security of systems and data, expecting that software products can be deployed in a set of completely independent environments that are not put together with other tenants' application instances and data.
- Simple billing logic: SaaS service providers need to bill for tenants' use of resources. For complex business scenarios, the relationship between compute, storage, and network resources will likewise be very complex, and the billing model is challenging, but in the shaft model, the billing model is relatively simple.
- Reduced failure impact surface: Because each customer's system is deployed in its own environment, if one of the environments fails, it does not affect the other customers' use of the software service.
inferior
- Scale issues: Since tenants' SaaS environments are independent, for every tenant onboarded, a set of SaaS environments need to be created and operated. If there are only a small number of tenants, it may still be manageable, but if there are thousands of tenants, it will be a very big challenge to manage and operate these environments.
- Cost issue: with each tenant having a separate environment, the cost of spending on a single customer would be very high and would significantly reduce the profitability of SaaS software services.
- Agile Iteration Problem: One of the strengths of the SaaS model is the ability to quickly respond to market demand and iterate on product features. However, a silo isolation strategy can hinder this ability to iterate with agility, as updating, managing, and supporting the SaaS environment for these tenants can become very complex and inefficient.
- System management and monitoring: It is simpler to manage and monitor the infrastructure deployed in the same set of environments. However, each tenant has a separate environment, and in this decentralized model, it is equally complex and difficult to manage and monitor each tenant's infrastructure.
shared model
It is believed that many SaaS service providers will prioritize the shared model, where multiple tenants share a set of infrastructure resources, which can make SaaS software services more efficient, agile, and cost-effective.
dominance
- Efficient management: Under the sharing strategy, it is possible to centralize the management and operation of all tenants, and the management efficiency is very high. At the same time, it will be easier to manage and monitor the infrastructure configuration. Compared with the shaft strategy, the product iteration and update will be faster.
- Low cost: A large part of the cost structure of a SaaS provider is the cost of infrastructure. Under the shared model, the service provider can dynamically scale the system according to the actual resource load of the tenants, so the infrastructure utilization will be very high.
inferior
- Tenant Interaction: Since all tenants share a set of resources, when one of them occupies a large amount of machine resources, the usage experience of other tenants is likely to be affected. In this scenario, some restrictive measures (flow limiting, degradation, server segregation, etc.) need to be designed in the technical architecture to make the impact controllable.
- Difficulty in tenant billing: under the shaft model, it is very easy to count the resource consumption of tenants. However, under the shared model, since all tenants share a set of resources, more effort needs to be put into counting the reasonable costs of individual tenants.
Segregation Mode
Large traditional enterprises prefer the traditional model of private deployment and personalized delivery because they need stronger controls and higher security. However, SMBs have limited ability to pay and their needs tend to be more standardized, so they prefer lower-priced, easier-to-subscribe SaaS offerings.
In order to meet the needs of different customers, there is another model that mixes the shaft model and the shared model, i.e., the sub-domain isolation model. In this model, it will be subdivided into basic domain, specialized domain, the basic domain is using the shared model, where all tenants share a set of resources; while the specialized domain is using the shaft model, where each tenant has a separate resource environment.
For most of the small and medium-sized customers, they are using SaaS products in the basic domain environment, and only a small number of large customers will use SaaS products in the dedicated domain, usually they have high paying capacity and strong strong isolation needs.
However, it should be noted that in order to avoid the emergence of multiple sets of product versions, SaaS service providers need to ensure that the product versions of the basic domain and the dedicated domain are consistent, and the personalized part is built as much as possible through the construction of PaaS platforms, so that ISVs can participate in the construction. Otherwise, once the degree of standardization of SaaS products is reduced, the subsequent maintenance of each version will turn into a disaster.
Positioning of multi-tenant systems
After understanding the various multi-tenant isolation models, let's summarize the positioning of multi-tenant systems.
Multi-tenant system is to meet the multi-user use of a set of products, and to achieve data and behavioral segregation between users, but according to the different needs of users, you can share or isolate the hardware and software resources, the system architecture can flexibly support a variety of isolation modes.
Capabilities required for multi-tenant systems
- Multiple tenants are supported to share a set of cloud resources such as compute, storage, and network resources. A single tenant can also have exclusive access to a set of cloud resources.
- Multiple tenants are able to achieve data and behavioral isolation between them, and are able to have decentralized and sub-domain control over them.
- The ability to support organizational structure-based management within the tenant allows for authorization and management of product capabilities.
- Different product capabilities can be supported to run on different cloud resources depending on customer requirements.
Multi-tenant conceptual model
Multi-tenant core concepts
- Tenant: generally refers to a business customer or an individual customer, where data and behavior are segregated between tenants.
- User: A specific user within a particular tenant who can log in to the SaaS system to use the software services by using login information such as an account name and password.
- Organization: If the tenant is an enterprise customer, it will usually have its own organizational structure.
- Employee: is a specific individual employee within the organization.
- Solution: In order to solve a certain type of business problem of customers, SaaS service providers combine products and services together to provide merchants with an overall packaged solution.
- Product Capability: It refers to the application of products sold by SaaS service providers to customers, and specifically refers to the ability to help customers realize the closed loop of end-to-end scenario solutions.
- Resource Domain: A set of cloud resource environments used to run 1 or more product applications.
- Cloud resources: SaaS products are generally deployed on various cloud platforms, such as Ali Cloud, Tencent Cloud, Huawei Cloud, and so on. The resources provided by these cloud platforms, such as computing, storage, network, containers, etc., are abstracted as cloud resources.
Conceptual modeling
- SaaS platforms can create and manage multiple platform users, multiple tenants, and multiple resource domains.
- A single platform user can be associated under multiple tenants, for example, the platform user, Zhang San, can be a user of tenant A or a user of tenant B. A single tenant can have multiple users under it.
- A single tenant can subscribe to multiple solutions, the solutions can package multiple product capabilities, and the product capabilities run on a particular resource domain.
- There are hierarchical relationships between organizational units, multiple employees can be under a single organization, and employees are bound to a single user.
Multi-tenant core scenarios
Intra-tenant modeling relationships
For SaaS products, the tenant is the topmost concept. The tenant has models of organizations, users, product capabilities, cloud resources, etc. inside the tenant, and the tenant is like renting a big house, and all other models are furniture or facilities inside the house.
Tenant identification
In various isolation modes, it is critical to recognize the identity of the tenant and obtain the resource allocation of the tenant. When a user logs in to the SaaS system, the system returns the tenant context information, and the context will contain information about the tenant to which the user is bound, as well as the isolation mode.
Tenant context information is appended to every system interaction throughout the system call chain so that the upstream caller knows which downstream resources to route to.
Tenant billing metering management
In the shaft isolation mode, the logic is relatively simple as the resources themselves are isolated, so they can be billed and measured based on occupied compute, storage, and network resources.
In shared mode, billing measurement is more complex, we need to be able to accurately capture the use of the actual resources by each tenant, and generally bill a combination of data based on request concurrency, storage capacity, and number of data objects.
Multi-tenant system application architecture
summarize
This paper firstly introduces what is multi-tenancy and compares the difference between traditional software model and SaaS model. By analyzing the three isolation modes of multi-tenancy, we gradually sort out the system architecture design of multi-tenancy, including conceptual model, scenario derivation, and application architecture. Expect to be helpful to readers, and feel free to communicate with us if you have any questions.
This article has been featured on, my tech site: Inside there are, algorithm Leetcode detailed explanation, interviews eight stock text, BAT interview questions, resume templates, architecture design, and other experience sharing.