Hello, I'm Master Tang~
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 isolated 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 shaft isolation model, which means that each tenant runs in a separate resource environment. This is shown in Figure 6-3.
Some people may think, isn't this the traditional software model? In fact, if these independent resources have standardized tenant identification, on-boarding process, billing system, deployment and operation process, it still meets the definition of SaaS, but 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 will increase 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, in which multiple tenants share a set of infrastructure resources, which allows SaaS software services to be more efficient, agile, and cost-effective. As shown in Figure 6-4.
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. This is shown in Figure 6-5.
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.
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.