Hello, I'm Master Tang~
The SaaS (Software as a Service) model is rapidly emerging in today's software industry. It has changed the traditional way of using software.
Multi-tenancy technology is at the heart of the SaaS model, a technology that allows multiple customers to share the same software system, but each customer's data is separate and does not interfere with each other.
This chapter will delve into the concepts, architecture, and implementation of multi-tenant systems.
Multi-tenancy overview
What is multi-tenancy?
Multi-tenancy is a concept unique to the SaaS (Software as a Service) space. In SaaS services, the term "tenant" refers to the customers who use the SaaS system.
So what's the difference between a tenant and a user? For example, let's say you're using a business-oriented (ToB) SaaS product. "Users" usually refers to the employees in your company who actually operate the SaaS system. A "tenant" is an entire company or organization. In other words, a tenant may contain multiple users.
Multi-tenancy is a software architecture that allows multiple tenants to share the same system instance while ensuring that each tenant's data and behavior are independent of each other and do not interfere with each other. In other words, although all tenants are using the same system, their data is completely isolated and secure.
Traditional Software Model VS SaaS Model
A traditional software project typically involves a software company developing a specific software system specifically tailored to a client's needs. This software is then deployed in a separate environment, usually a server within the organization.
The SaaS model is different in that it deploys software services in a cloud environment. Different customers are able to use the same software services through browser or web access. It's like a buffet restaurant that prepares a wide variety of dishes that anyone can come in and taste without having to cook for themselves.
Multi-tenant scenarios
For enterprise-oriented (ToB) SaaS products, multi-tenant usage scenarios generally involve three usage roles: business owners, employees, and SaaS platform operations.
1. Business owners
Business owners, i.e. the managers of a company, are the direct customers of the SaaS platform. To subscribe to and use a SaaS product, a business owner first creates a "business account" (a.k.a. a tenant) on the SaaS platform.
In this process, the business owner needs to register a company account and fill in the relevant information. Once this is done, the SaaS platform system creates an exclusive "tenant space" for the business owner.
Business owners can then order the products they need and add employee accounts in this space. Once employees are added to the tenant, they can use these products by logging into the SaaS platform.
2. Employees
An employee may be added by more than one organization, i.e. the user belongs to more than one tenant. This means that employees need to switch to the corresponding tenant, depending on the situation, when using the SaaS platform.
For example, switch to company A for tasks that deal with company A today, and switch to company B for tasks that deal with company B tomorrow. This tenant-switching design allows employees to freely switch between multiple corporate accounts to avoid identity confusion affecting the usage experience.
3. SaaS platform operations
The main responsibility of the SaaS platform operations team is to manage the tenants. They need to ensure that each tenant's permissions, resource allocation, and products are properly managed.
For example, when a business owner adds a new employee, the platform must ensure that the employee only has access to the data of the organization to which he or she belongs. SaaS platform operations can also respond quickly if a business owner wants to adjust a subscription.
Tenant management involves a series of complex operations such as privilege control, resource scheduling, capacity provisioning, billing management, etc. It is the role of the SaaS platform operations team to ensure that all this runs smoothly.
SaaS multi-tenant isolation model
SaaS multi-tenant isolation model
In the SaaS model, resource isolation between multiple tenants is a fundamental and critical part of the process, and SaaS providers need to build a shared environment that can be accessed by multiple tenants at the same time, while ensuring operational efficiency and controlling costs.
Although everyone is using the same set of SaaS product services, access to resources must be strictly segregated to ensure that tenants do not interfere with each other.SaaS resource segregation typically consists of the following levels:
1. Segregation of infrastructure
The first layer mainly refers to the infrastructure resources on which the SaaS system runs, such as computing resources (CPU, memory), storage resources (database, file system), network resources (IP, bandwidth), and so on.
These resources are segregated primarily to ensure that different tenants do not compete with each other for resources when using the system.
2. Segregation of organizational competencies
The second layer of isolation involves the isolation of organizational permissions, including organizational information, user accounts, roles, permission configurations, and product authorization relationships. This data determines who can use what features and who has permission to operate what.
The purpose of organizational privilege segregation is to allow each tenant to have its own independent organizational structure and privilege settings that do not conflict with the operations of other tenants.
3. Segregation of operational data
The last layer of isolation involves business data generated during system operation, such as orders, invoices, operation records and data reports. Through fine-grained data permission configuration, this information can be completely segregated between different organizational units, thus safeguarding the privacy and security of business information.
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 implement a multi-tenant isolation architecture, we need to first understand several common multi-tenant isolation patterns.
shaft isolation mode
Some SaaS providers choose the silo isolation model, which means that each tenant runs in a separate resource environment.
Some people may think, isn't this a traditional software model? In fact, if these independent resources have standardized tenant identification, on-boarding process, billing system, deployment and operation processes, it still meets the definition of SaaS, only to provide each customer with a set of independent infrastructure.
vantage
- Meet the need for strong isolation: Some customers have extremely high requirements for system and data security and expect to operate in a completely separate environment, avoiding mixing with other tenants' application instances or data.
- Simple billing logic: Resource usage billing can be complex for SaaS providers, especially in scenarios involving compute, storage, and network resources. However, in a silo model, where each tenant is an independent environment, the billing model is relatively much simpler.
- Reduced failure impact surface: Because each customer's system is independent, a problem in one environment will not affect the experience of other customers.
drawbacks
- Difficulty in scaling: Each new tenant requires the creation of a separate set of environments, which can be handled by a small number of tenants, but in the face of thousands of tenants, the difficulty of managing and operating these environments increases exponentially.
- High cost: Separate environments for each tenant drive up the cost of machines, resulting in a significant reduction in the profitability of SaaS services.
- Agile Iteration Constrained: One of the strengths of SaaS is the ability to quickly iterate in response to market demand, but the siloed model makes this difficult to operationalize because updating and managing each tenant's separate environment is time-consuming and complex.
- Complexity of system management and monitoring: It is relatively simple to manage and monitor the infrastructure in the same environment, but when each tenant is independent, management and monitoring in this decentralized model can become extremely challenging.
shared model
It is believed that many SaaS providers will prioritize the shared model, which means that multi-tenants share a set of infrastructure resources, which can make SaaS software services more efficient, agile, and cost-effective.
dominance
- Efficient management: Under the shared model, it is possible to centralize the management and operation of all tenants, greatly improving management efficiency. At the same time, configuration management and monitoring of the infrastructure is simpler. Compared with the shaft model, the product iteration and update speed is faster under the shared model.
- Low cost: Infrastructure accounts for a large percentage of the cost of SaaS service providers. Under the shared model, the service provider can dynamically adjust the system according to the tenant's actual resource usage, which greatly improves the utilization rate of the infrastructure and thus reduces the overall cost.
inferior
- Tenant Interaction: Because all tenants share the same set of resources, if a tenant occupies a large amount of resources, it may affect the usage experience of other tenants. To solve this problem, it is usually necessary to design some restrictions (e.g., flow limiting, degradation, server isolation, etc.) on the technical architecture to control the scope of influence.
- Difficulty in tenant billing: In the shaft model, it is easy to count the resource consumption of individual tenants. In the shared model, on the other hand, since all tenants share resources, accurately calculating the usage cost of each tenant will be more complicated, requiring more effort and technical input to achieve reasonable billing.
Segregation Mode
Large enterprises tend to prefer the traditional model of private deployment and personalized delivery because they need greater control and higher security. SMBs, on the other hand, tend to prefer SaaS offerings that are less expensive and easier to subscribe to because of limited budgets and often more standardized requirements.
To meet the needs of different customers, there is also a sub-domain isolation model that incorporates the shaft model and the shared model.
In this model, resources are subdivided into basic and specialized domains: basic domains use a shared model, where all tenants share a set of resources, while specialized domains use a silo model, where each tenant has a separate resource environment.
Most small and medium-sized customers typically use SaaS offerings in the base domain, while only a few large customers with strong payment capabilities and the need for strong isolation choose to run SaaS offerings in a dedicated domain.
It is important to note that in order to avoid generating multiple product versions, SaaS providers need to ensure that the product versions for both the base and private domains are consistent.
As much as possible, personalized requirements are implemented through PaaS platforms, allowing ISVs (independent software developers) to participate in the construction. Otherwise, once the SaaS product is less standardized, maintenance of multiple versions will become extremely difficult.
Positioning of multi-tenant systems
After understanding the usage scenarios of multi-tenancy, and the various multi-tenant isolation models, we can summarize the positioning of multi-tenant systems:
The core purpose of a multi-tenant system is to allow multiple enterprise users to share a set of SaaS products, but at the same time ensure that the data and behavior between enterprises is completely isolated. Through this design, the system is able to provide flexible resource allocation and efficient management while meeting the needs of different users.
According to different user requirements, multi-tenant systems can make adjustments in resources to flexibly support resource sharing or segregation. For example, for cost-conscious customers, a shared resource model can be used, while for customers with high data sensitivity, independent resource allocation methods such as shaft segregation can be used.
This flexibility allows SaaS providers to find a balance between resource efficiency and the individual needs of their customers, whether it's reducing costs or meeting high security requirements. Capabilities required for multi-tenant systems include:
- Supports multiple tenants sharing the same set of cloud resources, such as compute, storage and network resources. It also supports a single tenant sharing the same set of cloud resources.
- Achieve data and behavioral isolation between tenants and the ability to decentralize and sub-domain control of tenants.
- Supports organizational structure management within the tenant to facilitate authorization and management of products.
- Depending on customer needs, different product features can be selected to run on different cloud resources.
Multi-tenant conceptual model
We've learned about the position of a multi-tenant system and the capabilities it needs to have. Now, let's dive into the conceptual model of a multi-tenant system. The conceptual model is the "backbone" of a multi-tenant system and helps us understand how the various parts of the system are organized and operate.
Core conceptual model for multi-tenancy
- person who leases: Typically refers to an enterprise customer where data and behavior are isolated between different tenants.
- subscribers: Specific users within a particular tenant use information such as account numbers and passwords to log in to the SaaS system and use the software services.
- organization: If the tenant is a corporate client, it usually has its own organizational structure.
- workers: Refers to specific members within the organization.
- prescription: To solve a customer's specific business problem, SaaS providers package a combination of products and services to provide a total solution.
- offerings: SaaS providers sell customers software applications that help them realize closed-loop solutions for end-to-end processes.
- resource domain: A set of cloud resource environments for running one or more software applications.
- cloud resource: SaaS offerings are generally deployed on various cloud platforms (e.g., AliCloud, Tencent Cloud, Huawei Cloud, etc.), which provide resources such as compute, storage, network, containers, and so on, which are abstracted as cloud resources.
SaaS platforms can create and manage multiple platform users, tenants, and resource domains. This model structure enables multiple enterprise customers and users to run on the same platform while being independent of each other's data and resources.
A platform user can be associated with multiple tenants. For example, Zhang San, as a platform user, can belong to both tenant A and tenant B. This design allows platform users to flexibly switch between the tenants they belong to, making it easy to work across different enterprise accounts.
It is also possible to have multiple users in a single tenant, allowing multiple employees within an organization to share the tenant's resources and services.
A single tenant can subscribe to multiple solutions, and one solution often contains multiple products to meet the diverse needs of enterprise customers. These products can run on specific resource domains, ensuring efficient management and resource isolation of different products within the same tenant.
The organizational structure within a tenant supports hierarchical relationships. Within a single organizational unit, multiple employees can be configured and bound to the platform user, making it easy for employees to access related services through their own accounts.
Examples of application scenarios for the conceptual model
1. Tenant and internal model relationships
In SaaS products, the tenant is the topmost concept, which can be understood as the renter of a big house, while the organization, users, products, cloud resources and other models inside the house are like various furniture and facilities in this house.
In other words, a tenant is a separate space that a SaaS product dedicates to each customer or enterprise, while models such as organization, user, product, and cloud resources are segmented structures within the tenant to support different usage requirements and permission assignments.
- Tenant: equivalent to the ownership of the whole house, i.e. the tenant has the right to use this house in the SaaS platform and is the top-level manager of all internal resources.
- Organization: Similar to the layout of rooms, each with a specific function (e.g., subsidiary, department), the organization structure helps companies map real-life management-level relationships within the platform.
- Users: like the people who move around the house, users are given different roles and permissions that determine who has access to which rooms and who can use which furniture.
- Products: Like a wide variety of furniture, appliances, and facilities in a home to meet different needs. Different tenants can choose from different product portfolios, adding or subtracting as needed to meet their business needs.
- Cloud resources: similar to infrastructure such as water, electricity, coal, etc., to support the normal operation of the functions in the house, to ensure that the product is stable and smooth to provide services.
Through this analogy, it can be seen that SaaS products take the tenant as the topmost concept, providing a set of independent space for the enterprise, and the various resources within the tenant are flexibly managed and used under this framework, so that the enterprise customers can obtain customized services and resource-isolated security.
2. Tenant identification
In multi-tenant SaaS systems, regardless of the isolation model, it is critical to accurately identify tenants and obtain the appropriate resource allocation.
When a user logs into the SaaS system, the system generates and returns tenant context information. This context information includes the tenant that the user is associated with and the corresponding isolation mode (e.g., shared or independent resources).
Tenant context information is attached to every system interaction throughout the entire system call chain. The tenant context is retained at every step from user request to internal system processing. This allows upstream request processing modules to know how to route and access downstream resources.
Tenant context information enables the system to accurately identify tenant identity and configuration during request delivery. The system dynamically selects databases, application instances, or network resources based on the context, realizing data and resource isolation and ensuring that access by different tenants does not interfere with each other.
3. Tenant billing and metering management
Billing metering management for tenants is an integral part of the SaaS platform. Billing varies in different isolation models.
Billing is relatively simple in the silo isolation model. Because the resources (compute, storage, network, etc.) used by each tenant are individually allocated, it is as if each tenant has its own piece of "independent territory".
Therefore, we only need to count the amount of resources occupied by each tenant to calculate the cost. This model is logical and clear at a glance.
Billing is a bit more complicated in the shared model. Because multiple tenants share the same pool of resources, the ideal is to ensure that each tenant only pays for the portion they actually use.
Typically, we consider several metrics in combination, such as the number of requests, storage capacity, and the number of data objects created. By combining these data, we can calculate the cost per tenant with relative accuracy.
Multi-tenant system application architecture
We have just explored the conceptual model and key design of a multi-tenant system. Now, let's look at how the application architecture of a multi-tenant system is built from layer to layer.
1. Application layer design
The main role of the application layer is to provide application services for specific user scenarios and help users complete operations in specific scenarios. The core functions of SaaS products are realized by orchestrating the various capabilities of the domain layer. The application layer contains two key modules:
- Tenant Operation Platform ModuleThis module is responsible for the overall operation and management of the SaaS platform, including customer management, tenant management, cloud resource management, order management, platform user management and data analysis. It is like the "command center" of the platform, which ensures smooth operation of tenants and helps the platform control the overall business.
- Merchant Back Office Module: This module is primarily for enterprise customers to help them manage the capabilities autonomously. It includes capacity subscription management, expense bill management, renewal management and capacity authorization management. The merchant backend makes it easy for customers to manage the services they subscribe to on the platform, and they can check their bills and fees at any time.
- Open Platform Module: This module provides third-party developers or partners with the ability to access and integrate interfaces.
2. Domain layer design
The core of the domain layer is to provide reusable business capabilities around core business objects, which is the result of reuse and abstraction of the system as a whole. It contains the following modules:
- Tenant Management Module: Responsible for tenant on-boarding management, including tenant qualification and auditing, and tenant isolation mode configuration. This module ensures smooth onboarding of new tenants and sets appropriate resource isolation modes. Provide a safe and independent environment for tenants.
- Product Management Module: Responsible for product version configuration, product capability management, and product lifecycle management.
- Cloud Resource Management Module: The management of cloud resources, resource pool management, and elastic scaling strategies are all realized in this module. It provides powerful resource management capabilities for the platform and ensures reasonable resource allocation.
- Billing Metering Management Module: It involves billing plan management, subscription management, fulfillment, renewal and billing statements. This module is key to the revenue of the SaaS platform, ensuring that the platform is able to accurately charge tenants with clear billing and smooth renewals.
- Operations Management Module: It includes customer operation, marketing management, order management and data report. This module provides comprehensive operation support for the platform, helping the platform to improve customer experience, optimize marketing strategy, and maintain good operation of orders and data analysis.
This article has been featured on, MyTech.com: Inside there are, algorithm Leetcode detailed explanation, interviews eight stock text, BAT interview questions, resume template, architecture design, and other experience sharing.