In this blog post I want to look at some advantages and disadvantages of multi-tenant apps and provide tips on how to mitigate the risks associated with such architecture.
Before we start, let's first define the terms that will be used in this post:
- Tenant - is an entity represented by a group of users who share common access with specific privileges and usually purchase a license with the SaaS product, a.k.a. customer/client.
- Single Tenant Architecture – each tenant has their own independent database and instance of the software. Essentially, there is no resource or data sharing happening between tenants.
- Multi-Tenant Architecture – There is (usually) a single instance of the database and software that serves the needs of all tenants. Tenant data is isolated and invisible to other tenants.
Comparison between different app architectures. Credits to https://medium.com/@alfredbeiley/benefits-of-choosing-multi-tenant-architecture-for-saas-app-47e753d0efff
Lower cost per each client
Mendix licenses are not cheap. Neither are Mendix cloud resources. If every customer needs a separate license and cloud instance, then those costs need to be covered in the price of your product, making it more expensive. Contrary to this, multi-tenant apps need only a single Mendix license and a single cloud instance per client. This can easily save a significant amount each year.
Unfortunately, there is no free lunch. Multi-tenant apps come with a higher risk as it becomes vital to properly configure and build your Mendix model, especially access rights and permissions. Just imagine what would happen if due to a modelling error, one tenant could suddenly see all user data or invoices from another tenant! Luckily, application code reviewer is here to check that no such error go unnoticed thanks to several rules specifically designed for multi-tenant apps.
Better resource utility
Most software exhibits so-called spiky usage patterns, i.e. load is not equally distributed over time, but tends to spike around periods of high activity. When each client has a separate runtime and database instances, then each instance needs to be large enough to accommodate the spikes. This might mean that you need to get a large cloud-node that sits idle most of the time just for that occasional spike.
Example of spiky behavior.
However, when multiple tenants are using the same node it is more likely that the load will be evenly distributed. Also, if there is a spike for one tenant then the full-power of the cloud-node can be used leading to better utilization of the available computing resources.
Again this is double-edged sword and there is a risk that a single tenant can negatively impact the performance for all tenants. So it is paramount to check the performance using Mendix specific tools such as application performance diagnostic. Otherwise, you might get complaints about your product being slow, due to one misbehaving tenant.
Adding customers becomes trivial
With single-tenant architectures, adding a new customer means setting up a new and separate instance of every system, such as runtime and database. Very often, the system needs to be initialized and populated with configuration and other data required for proper functioning.
In multi-tenant architectures, adding a new tenant becomes as easy as adding a new record in a database.
However, "With great power comes great responsibility", so one has to be careful that different tenants are completely separate in the data that they can see. To ensure this, the application model security tool scans the app and reports on what data a specific user can see and edit.
Easy maintenance
Another common pain with single-tenant configurations are updates and bug-fixes. Every time a new version of the product is released all tenants need to be updated. As customer sluggishly and reluctantly adopt new versions, you often end up supporting multiple versions of your tool. This can bring about a lot of headaches, that I have experienced first-hand.
Luckily, with a multi-tenant setup these problems go away, as all tenants can be upgraded with less effort and all of them will be using the same, and latest version of your product.
The joys of debugging. Credits to http://comicstrip.com/
The disadvantage is that a single bug in a new release will affect all tenants. So it is vital to have automated regression tests (see application test suite) that are executed with every build of your product. Also be sure to use the code reviewer tool which checks for over 100 common bugs and code smells. Otherwise, a small bug could affect all your tenants and wreck customer satisfaction.
Closing remarks
Multi-tenant architecture offers many benefits to those who choose to adopt it. However, it also comes with disadvantages, which need to be managed correctly. Otherwise, your product and brand can be severely damaged. Using the right tooling when building multi-tenant application with Mendix can make all the difference and help you get the benefits while avoiding the risks.
Get in touch
