Advantages and disadvantages of multi-tenancy
The most obvious and important benefit of multi-tenancy is the reduction in hosting costs through optimal use of resources, but there are other very important benefits that this architecture can bring to your business:
- Fast and easy scaling, allowing as many resources as needed to be allocated without downtime and without many administrative routines.
- High level of protection against malware.
- Software updates and maintenance are handled by the SaaS providers.
- Reduced costs and time spent on material management.
- Easy integration with third-party software through the use of APIs.
Potential disadvantages include limited customisation options compared to single-tenant architecture, some security and compliance issues, and the ‘noisy neighbour’ effect, which can occur when one client uses an inordinate amount of CPU and slows down other tenants’ applications.
To summarise all of the above, the single-tenant architecture offers a high level of security and customisation and is a good choice for large enterprises. The multi-tenant architecture is a more cost-effective and highly scalable model that is well suited to most enterprises.
Multi-tenant SaaS models
The most common multi-tenant SaaS models are the following:
- Container-based multi-tenancy: Typically, in a containerised environment, each client’s (tenant’s) data is isolated, but a common application server is shared between them. However, it is possible to run both the application server and the database in a completely isolated tenant container.
- Virtualisation-based multi-tenancy: this model is very similar to single-tenancy and offers a very high level of security and isolation because each client has its own VM with application and database. Despite this, it is only occasionally used because of its low scalability and high cost.
Database by tenant : In this case, each tenant has its own database. Only the application server is shared and can be resized vertically or horizontally if necessary. This approach works well for multiple tenants, but is not suitable for applications of unknown scale, due to the large number of databases required.
Single multi-tenant database: This model is very popular as it provides a single storage for all users, which can be easily expanded when necessary. The main disadvantage of this approach is the high risk of the ‘noisy neighbour’ effect, mentioned above.
- Sharded multi-tenant databases: This model allows tenant data to be stored in multiple databases. Tenant data is divided into a set of segments (shards) and multiple users can use the same shard. However, this model ensures that a particular tenant’s data will not be spread across multiple shards. This is a win-win approach to building a highly scalable application.
Points to consider when designing a multi-tenant application
- Type of isolation: As users share resources in multi-tenant environments, their security and privacy must be assured by the SaaS provider. You can choose between three of the most commonly used isolation models: silo, pool, bridge and tiered isolation.
- Silo SaaS providers offer separate isolated clusters for each tenant. This approach is similar to single tenancy and requires additional infrastructure, development and management costs, but ensures a high level of privacy.
- Pool isolation allows users to share the same infrastructure and provides efficient scaling of resources, but has security weaknesses.
- The bridge model is a mixture of silo and pool isolation, with infrastructure shared and isolated at the same time.
- Tiered isolation involves different types of isolation depending on the subscription plans, e.g. free tier tenants use shared infrastructure while higher tier tenants have isolated environments. - Expected resource consumption: carefully analyse the number of tenants you need to manage, the infrastructure costs per user, the storage and CPU usage, and the expected benefits. Also keep in mind that your multi-tenant SaaS needs to collect many resource consumption metrics very carefully and regularly.
- Customisation options: try to consider the level of customisation your tenants need to manage their environments and the level of control you need.
- Support clients: consider very carefully what kind of support your tenants might need from the environment and infrastructure, what content and resources should be shared, and who will manage their additional requests.
- Infrastructure limits: It is important to understand how the infrastructure that supports your multi-tenant architecture works and whether there are limits to the resources you consume.
- SLA (Service Level Agreement): this is a very important document that measures the customer’s expectations and helps to understand their needs. It should definitely contribute to your multi-tenancy model.
- Areputable hosting provider**:** finding hosting for your SaaS that is powerful and scalable enough to ensure smooth and secure software access for customers can be a real challenge. Hidora Cloud covers all these needs and more: our inspired experts will help you build your application infrastructure.
Conclusions
Getting the right multi-tenant SaaS architecture in place is a crucial factor that affects the quality of the service provided and your business in general. Consider all of the above fundamental factors from the start to have a clear understanding of the software you are developing and all of your customers’ needs.
