4 Reasons to switch to a multi-tenant architecture with Mendix
In this blog post I want to look at some advantages of multi-tenant apps and caution for 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.
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. Contrary to this, with multi-tenant apps only a single Mendix license and a single cloud instance is needed 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 right 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.
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 many 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.
Just make sure that new releases do not contain any bugs by scanning them with application code reviewer which checks for over 100 common bug 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, these benefits come with elevated risks, which need to be managed correctly. Otherwise, they could severely damage your product and brand. Using the right tooling when building multi-tenant application with Mendix can make all the difference.
I hope you enjoyed reading this post and that it helps you build great apps.
Originally published at Andrej Gajduk’s Blog.
From the publisher -
If you enjoyed this article you can find more like it at our medium page or at our own community blog site.
Interested in getting involved with our community? You can join us in our slack community here or for those who want to be more involved, look into joining one of our meet-ups here
