Multi tenancy or multi instance? [closed]

Question

I'm trying to build a web-based SaaS solution, and I hit a road where I'm not sure to use multi tenancy or multi instance. I will try to describe what I'm trying to achieve, and each approach advantages and disadvantages (my opinion, according to what I read). Please include your suggestions in case I missed anything in one approach over the other.

The application that I'm trying to build is, as I mentioned, a SaaS solution where companies can create their accounts, and each account/company has it's own users, customers, products, services...etc. Each user; who is a company employee; related to one account/company will have access only to his/her company customers, products, and services. Companies could have unlimited number of customers, products and services, thus each company should have it's own data center.

For that I decided to create a shared database (saving all users credentials for login purposes) and multiple databases shared schema (database per account/company). Basically, Multi Tenancy.

Then somebody suggested to use Multi Instance instead, where each company will have its own instance of the application (i.e. code, libraries, database, frameworks... etc) totally separated from the other companies. This sounds better as I don't have to take care of an extra layer where I need to make sure that each tenant's users have access only to their company's data. I think it's good to mention that I'm depending on Docker to achieve this approach (I've never used it before), but I think it lacks features (more on those later) I will need in the future (at least I didn't find them with a little bit of search).

However, each approach comes with pros and cons, so I couldn't make a decision with which approach to go. Here is a list, but bear with me as I lack the knowledge in them both, so there could be something that I'm not aware of, or a solution for a problem I didn't find on the web: [Each approach has an ordered list of which I followed a one by one comparison]

Multi Tenancy:

1. Shared host/hardware, shared code, and multi database.
2. It's easier to extend the functionality of the code and fix bugs (shared code).
3. It's harder to extend the hardware (could use a cloud service), or move the database of individual tenant to another system without doing changes to the code.
4. Most importantly, as I mentioned before, I need to add an extra layer to the system to make sure that the user is actually belongs to his/her company, and not accessing other company's information.

Multi Instance:

1. Shared or unshared host/hardware, code per instance, and database per instance.
2. It's harder to extend the functionality or fix bugs (I'm not sure if there is a way to do it in Docker where you can add functionality/feature to one instance or Docker container, and deploy it to the others).
3. It's easier to move the whole instance to a different host/hardware.
4. As the instance, I don't need to take care of that layer as each instance will have its own database.

All of the advantages and disadvantages are redundant in case I want to do anything manually (as creating an instance for each tenant manually), and that's why I doubt the Docker solution, unless there is a way to solve that, which is maybe the main reason of the question. I would appreciate it if you would answer the question with references to the solutions, and why do you think this approach is better than the other.

In case that would help (maybe?), we're using Laravel as the main framework for the back-end (all RESTfully).

Fibroid

Related post - Saas: Single-instance vs Multi-instance vs Single-tenant vs Multi-tenant? – Overblown

Answer 1

You don't need different databases for each customer if they are going to have shared schemas anyways. Most SaaS software is multi-tenant and works in this fashion, a common database with application logic to make sure users can only access things they should be allowed to access. E.g. Facebook doesn't have billions of databases, one for each user, to make sure we can't see each other's non-public photos.

Also, the problems you're trying to solve for don't seem as though they should have any bearing on the portability of your application, or your ability to move them to the cloud. If you treat backing services, e.g. database(s), as attached resources then it doesn't really matter if you have one or many (though I still recommend you have just the one).

I'd recommend reading the 12-factor principles for SaaS development and deployment. They are a great starting point for thinking about architecting software that will work easily in a cloud-native environment. I would focus on solving the business problems of your software, and architecting it in a cloud-native way, e.g. per the 12-factor principles.

Nothing about the problems you've described suggest that Docker vs. not-Docker is even a relevant concern at this time. I.e. all your proposed approaches could be done fairly similarly with/without Docker. Docker solves problems of process isolation, packaging OS-level dependencies, reducing compute resource overhead, consistency between development and production, etc. and only seems indirectly related to what you're after.

Harrietharriett

Thanks for your answer. I see why you said that I don't need a database per tenant as I have a shared schema, but my assumption was depending on two things: First, a tenant could have a huge amount of data in his/her data center, while another one would have less. So the one with less amount would suffer a performance (maybe?). Second, some tenants might need an extended service (need a new table), it would be easier to include that for one tenant's database (add code) than in one database (need to modify the code)... – Fibroid

"First, a tenant could have a huge amount of data in his/her data center, while another one would have less. So the one with less amount would suffer a performance (maybe?)" Or maybe not? There are better solutions to optimizing queries than a different database for every tenant. "Second, some tenants might need an extended service (need a new table), it would be easier to include that for one tenant's database (add code) than in one database (need to modify the code)." There are better, more "cloud-native" patterns for this sort of thing... – Harrietharriett

You may want to consider a microservices-like architecture. You can have a single frontend, which can communicate with different backend services via APIs, and expose only the relevant services to a given user. Different databases for different services makes sense, not for different tenants. I wouldn't start with the plan that every user is going to get an entirely different service. – Harrietharriett

Upvote for your answer and your comments :) – Fibroid

Answer 2

Multi Tenancy is way to go, it is cost effective and more maintainable. Imagine you have 10 customers on 10 different versions of your application, supporting them becomes big deal. With multi tenancy you can auto scale based on the load and scale down when the load is less, with multi instance you may have to make sure at least one instance is available for each customer.

Few other reasons why I would go with Multi Tenancy

1. One version to build and deploy
2. Share resources like caching
3. Testing only one version of your application
4. Security testing will be simplified
5. Make use of CDN effectively

Passed

Answer 3

Other's had these problems before. E.g. there's sth. out there called the SaaS Maturity Model. I think that most successful models started out with the functionality first, and the platform as secondary concern. So I would go with an instance per customer strategy first. Anyway how many customers will there be at the beginning? Is it more likely to fail because the customer don't like the functionality or because you are using multiple instances coming of course with a ops overhead?

=> Focus on the product/functionality first. So aim for level 1, focus on other levels later.

With Docker (at least from my perspective as one guy, that has not done a lot with it): The artifact of your development is a runnable container image. When this artifact is published to a repository it should be very easy to update all instances to use this new artifact. So with a little scripting and perhaps sth. like Kubernetes it should be doable to move even a lot of instances to a new version. So I think new developments like Docker do make multi instance setups even more feasible.

I'm doing also a SaaS product for our company. For us it is also multi instance due to business concerns:

1. Our customers are very keen of keeping data separate from competitors. That is much easier to show with a multi instance strategy.
2. Customers want some control of the release cycle sometimes. For example they have to communicate changes in functionality to employees or a business process is in progress that does not allow an upgrade. So they might want to wait with a new version or even skip it. Again much easier with an instance per customer.

As always with these kinds of questions, I'm giving my opinion and my experience here. It really depends on your use case - SaaS has a lot of variety.

Britton

Thanks. I'll answer your questions as a start. There will be two customers (companies) at the beginning, so two instances. For the second question, just another SaaS, it could be a success or a fail, however, there would be two customers at least. It's understandable that the whole thing depends on the use case, but the maturity model that you referenced is treating the multi instance solution as a lower level (level 1) and the other multi tenancy solution (level 2) as a higher level, but I don't see it as that. It also didn't mention anything about moving from level to another... – Fibroid