Multi-tenant SaaS: Where to Start?

Multi-tenancy is widely used in cloud computing, especially it’s a crucial feature if we talking about SaaS solutions. The idea behind the multi-tenant architecture is that one software server, database, storage or network controller can be used by multiple customers while each client’s data is hidden from others. Single-tenancy is opposite to this and means that one software instance serves one application.

Pros & Cons of Multi-tenancy

The most obvious and the most significant benefit of multi-tenancy is cutting hosting expenses through the maximally effective usage of resources, but there are some more very important advantages this architecture can give your business:

• Fast and easy scaling, which allows allocating as many resources as it’s needed without downtimes and lots of administrative routines.
• High level of protection from malicious software.
• Software upgrades and maintenance are handled by SaaS providers.
• Reduced costs and time for hardware management.
• Easy integration with third-party software through the use of APIs.

As a potential downsides it’s worth mentioning limited customization options comparing with single-tenant architecture, some security and compliance issues, and the “noisy neighbor” effect, that may occur when some customer uses an inordinate amount of CPU and slows down the other tenants’ applications.

To summarize all the above points single-tenant architecture provides a high level of security and customization and is a good choice for large enterprises. Multi-tenancy is a more cost-effective and highly scalable model that perfectly suits most businesses.

Multi-tenant SaaS Models

The most common multi-tenant SaaS models are the following:

• Container-based multi-tenancy: as a rule in containerized environment each client (tenant) data is isolated, but one common application server is shared between them. However, there is a possibility to run both the app server and the database in a completely isolated tenant’s container.

• Virtualization-based multi-tenancy: such a model is very close to single-tenancy and provides a very high level of security and isolation because each customer has his own VM with application and database. In spite of this, it’s used once in a while because of poor scalability and expensiveness.

• Database-per-tenant: in this case, each tenant has its own database. Оnly the app server is shared and can be scaled vertically or horizontally if it is needed. This approach works well for several tenants but doesn’t suit apps with an unknown scale because of the huge number of databases required.

  

• Single multi-tenant database: this model is very popular as it has single storage for all users, which can be easily scaled up when it’s necessary. The main disadvantage of such an approach is the high risk of “the noisy neighbor” effect, which was mentioned above.

• Sharded multi-tenant databases: the pattern allows to store tenant data across multiple databases. Tenants’ data is divided into a set of segments (shards) and few users can use the same shard. However, this model ensures the data for any particular tenant won’t be distributed between multiple shards. It is a win-win approach to build a highly scalable application.

Points to Consider Designing Multi-tenant Application

• Type of isolation: as users share resources in multi-tenant environments, their security and privacy should be assured by SaaS provider. You can choose between three the most commonly used isolation models: silo, pool, bridge and tier isolations. – Silo SaaS providers offer separate isolated clusters for each tenant. This approach is similar to single-tenancy and requires additional costs on infrastructure, development and management, but ensures a high level of privacy protection. – Pool isolation enables users to share the same infrastructure and provides effective resource scaling but has security weaknesses. – The bridge model is a mix of silo and pool isolations, having shared and isolated infrastructures at the same time. – Tier-based isolation implies different types of isolation based on subscription plans, e.g.: free tier tenants use shared infrastructure while premium ones have isolated environments.
• Expected resource consumption: analyze carefully how many tenants you have to manage, infrastructure costs per user, storage and CPU usage, and anticipated profit. Also, keep in mind that your multi-tenant SaaS should collect a lot of resource consumption metrics very carefully and regularly.
• Customization options: try to examine what level of customization your tenants require to manage their environments and what level of control you need.
• Customers support: research very attentively what type 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: there should be a clear understanding of how the infrastructure that supports your multi-tenant architecture functions and if there are limitations on the resources you consume.
• SLA (Service Level Agreement): this is a very important document that measures client’s expectations and helps to understand their needs. It definitely should contribute to your multi-tenancy model.
• Reputable hosting provider: finding hosting for your SaaS that is powerful and scalable enough to ensure smooth and secure access to software for clients can be a real challenge. Hidora Cloud covers all these needs and even more: our inspired experts will help to build the infrastructure for your app.

Conclusions

Building the right multi-tenant SaaS architecture is a crucial factor that affects the quality of service provided and your business overall. Consider all the mentioned above basic factors from the very beginning to have a clear understanding of what software you are developing and all your customers’ needs.