Multitenant apps — Why and how?
For some reason, there are still many developers that have no idea what multitenancy is, or what’s all about.
Definition and legal agreements
A simple definition would be a single instance of an application, that serves different tenants/groups of users/organizations/companies.
Is it legal? Of course: You are providing the same software for different clients. As long as their information is secure, you’re fine.
Comparison
Let’s say you are having an online store app, that is “sold” to Client X, Client Y and Client Z.
1. You could have a single tenant and for each client, you have only one instance of your software (each one with its instance of UI, microservices/backend, database(s) ).
Benefits:
a) Each client with its own hardware means that it will be easier to secure (only the users from that specific client could log in) and easier to scale in case of high load (only the hardware for that specific client will scale)
b) Easy to customize if needed.
Drawbacks:
a) When you want to deploy a new feature/hotfix you’ll need to deploy for each of those 3 clients (not only one single deploy)
b) Maintenance and monitoring will be harder (since you have now 3 environments to take care of)
c) Cost: You need to pay for 3 environments not only for one.
2. Multi-tenant, which means, a single instance of the app (only one UI, one set of microservices/backend, one set of databases). Each set of users will be able to log in only on the “space” of their organization, and only that part will be visible to them.
Benefits:
a) Low cost since the environment costs are split between the clients (since they all use the same instance). You can think about less money spent on licensing.
b) Maintenance and monitoring would be easier. You need to keep your eyes only on one environment, not on 3
c) Deployment faster (one vs 3)
Drawbacks:
a) Harder customization (but not impossible).
b) You’ll need extra checks for security since users from different companies will use the same instance of the product
Keep in mind that in a multitenant app, the tenants are invisible between them, they are isolated logically but not always physically.
Usecases for multitenancy
Any application that is used/sold to multiple clients, and they all use the same stack of features (or most of the same features). I am not sure that feature, algorithm or services are the correct words, but hopefully, by the end of the article, you’ll get what I am trying to say.
Other classical use cases are the fancy words that are used nowadays when you talk mostly to cloud developers: SaaS (software as a service), IaaS (infrastructure as a service) and PaaS (platform as a service).
If you make any piece of software generic enough to be used by multiple clients, and they bought it and use it, it can be made multitenant.
Data-management
In single-tenant, everything is simple, but here you have 3 options (or only about 3 I am aware of)
- Single database for everyone.
You add a column for more or less everything that should be tenant-specific and you add in there the tenant id. You can add indexes if needed for this tenantId or for clientId if you want to link something to the client (since for sure the client will be linked to the tenant)
Benefits:
a) Easy to maintain database. (Easy for the DevOps guys to keep track of the changes of the database if they need to, or for the database admins if they still exist in companies)
b) Easy to add new clients, since this will mean just some more inserts into the current tables.
Drawbacks:
a) Not too much “flexibility” for customization, (but if you are selling a PaaS, you don’t really care about this)
b) Big databases eventually might become bottlenecks for the entire system and since you have only one and tenants are different only by an id from a column, it might be hard to separate them (it might be hard to extract a specific tenant into a separate database if needed).
c) Hard to separate them, add a generic and good permission layer to be sure everything is invisible from one client to another and they can’t access data from someone else.
d) Backup and recovery might be pretty hard.
e) Optimization of the database will get harder and harder, and queries and general will eventually be slow because as you can imagine, you can’t compare searching for a product for example in only one client’s data vs searching in all the products of all the clients. - Single database, multiple schemas — each client with its own schema. You can imagine schemas as umbrellas. You have the same mechanisms, but over them, you have the same type of material with different colours, with which an entire umbrella is created.
Benefits:
a) Easier to separate and work with the permissions. All the users from a client will get access only to that specific client’s “umbrella”.
b) Still only one database, so low resources and changes will be applied only to one physical space.
c) Pretty easy to extend, when a new customer will come, since, the new schema is just a copy of another existing one
d) Easy to customize, since the schemas are not connected between them, so each client can extend its features based on his needs.
e) Easy to extract a schema/data of a specific client in a separate database if needed.
Drawbacks:
a) The data is kept together so, it’s still in the same physical space, so it’s separated more from the logical perspective.
b) Backup and recovery might be pretty hard since you can backup or restore only the entire database, not only a specific schema/data of a specific client. If an operation will fail for a specific client, the entire thing will be rolled back, which is not really ok. - Separate databases. Each client with its own database
Benefits:
a) Simple to add a new client. Maybe even more simple than in the multiple schema version.
b) Scaling is simple since it can be done for each client that needs it.
c) Backups, recovery and all the other actions on the database will be without any headaches.
d) Maybe it’s the most secure way of doing multitenancy
e) Most flexible for new features for clients
Drawbacks:
a) The biggest cost. You will probably need more hardware, more admins, more time for maintenance and so on.
Conclusion
You can think of multitenancy, as being a way for clients to be isolated but split the costs for computational power, storage and network band, and for you to develop and maintain only one platform for all the clients. Even if this sounds like the future for you, you should keep in mind the drawbacks and this isn’t any kind of a silver bullet; it needs complex development, limited customization, and you really need to be careful on the security part vs performance. You can imagine if all your clients will have “Black Friday” at the same time, you really need to be hands-on and not just throw autoscaling on.
