The pool model
The pool model is a prevalent design approach for implementing multi-tenancy, particularly favored for its resource efficiency. In this model, multiple tenants share the same resources, such as compute and storage, while their data and configurations remain logically isolated. The approach is akin to a public swimming pool where everyone shares the water but has their own designated lane to swim in. The key advantage is the efficient use of resources, which translates into cost savings. However, the challenge lies in maintaining data isolation and security in this shared space.
The following diagram (Figure 8.3) illustrates the pool model:
Figure 8.3 – The pool model
Levels of isolation
The pool model offers nuanced levels of isolation due to the shared nature of resources, each balancing resource utilization and data isolation while incorporating robust security measures such as encryption and strict access control policies:
- Database segregation: Database segregation can occur at various levels, including the schema, table, or even record level. Each tenant’s data can be isolated within the same database instance, offering a balance between resource utilization and data isolation.
- Namespace segregation: Another approach is to use namespaces to isolate tenants within the same application or service. This is particularly useful in Kubernetes environments where each tenant can have its own namespace, allowing for logical isolation while sharing the underlying cluster resources.
- Attribute-based segregation: This approach focuses on isolating resources and data by using distinct attributes such as tags or identifiers that are specific to each tenant. These attributes can be integrated with ABAC mechanisms to achieve an effective layer of isolation where fine-grained permissions are defined based on the attributes attached to the underlying resources and data. For example, consider a cloud storage service where multiple tenants share the same storage infrastructure. Each file uploaded by a tenant could be tagged with a unique tenant identifier. When a tenant tries to access a file, the ABAC mechanism checks the tag against the tenant’s identifier to ensure they are authorized to view or modify the file. This way, even though the storage resources are shared, each tenant’s data remains logically isolated and secure.
Use cases
The pool model is highly versatile and can be applied in various scenarios. It is particularly useful for SaaS providers who have a large number of tenants with similar needs but varying scales. This model is also beneficial for start-ups and SMBs who are SaaS customers looking for cost-effective multi-tenancy solutions.