For any digital business with a SaaS product, tenancy is a key consideration.
Your tenant and isolation strategy will have an impact on your underlying infrastructure, costs, and how quickly you can roll out new features.
In this piece, we look at the major isolation patterns and their use-cases, helping you determine which is the best fit for you.
What is a tenancy isolation strategy?
In SaaS, a tenant is a customer accessing software. Like a tenant in a building, a SaaS customer rents access to the software they want to use, sharing it with other customers/tenants.
However, the way tenants are separated when using a SaaS product is a little more complicated than a dividing wall.
Each strategy has its benefits, drawbacks and use cases, which we’ll be exploring today.
Strategies of tenancy isolation
The three main strategies of tenant isolation differ in how many resources each tenant shares.
The silo model, as the name suggests, sees tenants sharing a few resources, with a boon to data security and a draw on efficiency. Likewise, the pool model is a more efficient use of resources at the expense of keeping tenants strictly separated.
The bridge model, on the other hand, is a hybrid of the two.
The terms single-tenant and multi-tenant are sometimes synonymous with the silo/bridge distinction but differ in a few areas we address below.
Source: AWS Big Data Blog
The silo model
The silo model sees more dedicated resources per tenant. This usually means each tenant will have (at least) their own database, but other resources can be allocated per tenant, too.
This approach is synonymous with ‘single-tenant,’ in that each (single) tenant has exclusive access to infrastructure and resources.
Advantages of the single-tenant/silo model
Single-tenant/silo architectures may be preferable where the use case requires:
- Strict separation of customer data, often for legal reasons
- Customisation of the service, enabled by each tenant having their own instance of the application running on their own dedicated infrastructure
- Highly dependable availability, in cases where tenants may need to draw heavily on infrastructure resources. The nature of single-tenant/silo means you’re never sharing resources
Disadvantages of the single-tenant/silo model
- The biggest disadvantage to this model is simply cost. For every resource that is allocated per tenant, the cost goes up
- Single-tenant/siloed SaaS users also bear the brunt of patching and other kinds of environment management, depending on which resources they’re allocated
Silo/single tenant model use cases
The most common use case for this model is legal or medical services where data is subject to stricter laws.
The pool model
The pool model – much more common than the silo – sees users sharing some or all infrastructure resources.
Tenants may share a database, and/or they may share the application layer.
Where tenants share a database, a SaaS app may separate data using a schema (a logical structure that marks up and separates data) as shown above.
The pool model is an example of a multi-tenant architecture, in that multiple tenants access the same resources. However, a bridge model, covered below, is also multi-tenant, the distinction laying in whether the vast majority of resources are shared (pool) or whether significant aspects of the solution are also siloed (bridge).
Advantages of the pool/multi-tenant model
- Both types of multi-tenant architecture (pool and bridge) use resources much more efficiently than the silo/single-tenant model. Many of the benefits are essentially downstream of this. For instance, shared resources make these models much more cost-efficient in terms of consumption, management, and rolling out of new features. For this reason, unless there is a strong case of a silo model, a form of multi-tenant is the default tenant isolation strategy
Disadvantages of the pool/multi-tenant model
- There is less scope for customisation of any of the resources tenants share
- There is less strict separation of tenant data
- There is more risk of ‘noisy neighbour syndrome,’ wherein another tenant’s use of resources – i.e. compute – negatively impacts the experience of other tenants
Pool/multi-tenant model use cases
Having more shared resources than the bridge model, the use cases of the pool model include solutions wherein there is little or tolerable risk of the noisy neighbour effect and no reason for customer data to be separated.
The bridge model
The bridge model is a hybrid between the silo and pool model. It’s also a multi-tenant architecture since tenants do share some resources, but in a bridge model, some resources are siloed.
As we can see in the figure above, the foundation for a bridge model is often some kind of shared database, though a bridge model may include a separated, per-tenant database or storage for particular data.
However, other resources can be shared, too. For example, it’s common for bridge-model SaaS products architected as microservices to deploy some services as silos and some as pools.
Advantages of the bridge model
- Depending on the use case, bridge models can be used to keep data safe, reduce noisy neighbour effects, and still benefit from efficiencies
Disadvantages of the bridge model
- Bridge models can be more complex to manage and deploy since there is a mix of infrastructures
Bridge model use cases
Bridge models may be used where some customer data is subject to strict laws or a need for isolation, and other cases where benefits of the pool and silo model are applicable simultaneously.
How we can help
We build cloud-native infrastructures, support complex mission-critical stacks 24/7, and help our partners stay secure through our VMaaS offering.
To find out how we could help you, or for anything else, just get in touch!