Multi tenancy or multi instance?

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 bare 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).

Answer 1

I am asking myself the exact same question at the moment.

I am leaning towards the multi-instance single tenancy solution but have not taken a definitive decision yet. Let me share some of my thoughts :

The main historical advantage of the multi-tenant architecture is a better use of infrastructure resources, by mutualisation (single OS, single Database, single application layer) and better occupying of said resources (when one user is away another can use the same resource).

It also greatly simplifies software lifecycle : you deploy new versions to you one instance, all the customers are updated at the same time.

It seems however, that recent advancements in cloud technology make the first class of advantages largely available in a multi-instance (instance-per-customer) architecture (I am thinking specifically of a platform like Jelastic here but I am sure there are others that provide the same features):

• Container-based PaaS
• Provisioning and auto-scaling of containers (elastic containers)

So hardware and platform management is not the Software provider's concern any more. Resources are mutualised much more efficiently than before at the infrastructure and plaform levels.

There will still be an overhead for multi-instance (some app and middleware will be ran N times instead of just one), but much lower than when using a separate (virtual) machine per instance. The database could be shared anyway (one schema per instance, several schemas per DB server)

Also :

• Automation of creation of new instances is possible via PaaS API
• Automation of deployment of new versions is possible via PaaS API, with zero downtime (takes some work to put in place)
• Scaling is always out, never up. We don't have to worry about huge datasets at the instance level.

Of course, we would need some kind of central service that manages all this automatically (e.g. creation of instance when a new user creates an account). This would also manage payment and licensing issues, interaction between instances etc. This central service might be quite complex and hard to develop, but the good thing is that we don't have to implement it upfront (now that we don't have much resource) whereas multi-tenant would need to be baked into the app from the start.

Which brings me to the final advantages of developing single-tenant for a very early stage (pre-invesment) startup project :

• Same (or almost same) version of the app can be deployed on-premises either as a virtual appliance or docker container or even on customer-managed machine (some companies are still reluctant towards the Cloud and it may help an early stage startup to not push out important early adopters)
• Faster to get a product out with limited resources (the application layer and database schema is quite less complex), can get a "dumb" single instance single tenant product out first (MVP) for early adopters and to show the business value of the app to potential investors, and add all the cloud automation later on
• Can be seen as a selling argument for customers worried about data security : the data is better encapsulated since every customer has his own schema or even database. Much less risk of "spillage"

NB: I am obviously thinking here of a business app where customers would be businesses (each with multiple individual users) and not individuals. It would not make any sense to run a separate instance of an app for each individual user (or would it ?)

Answer 2

Supporting both options is possible also (a pool of tenants across multiple instances).

I favor multi-instance cause of the natural isolation. Each customer's instance runs in it's own processes and it's data is isolated in it's own database. You can upgrade instances to new versions on a per customer/instance basis when desired.

Tenant based systems come with a information security risk. Just consider how easy it is to forget a "WHERE tenantId = x" clause. The main reason to use a tenant capable system would be performance, processes are heavy weight, by sharing a process you can potentially get more out of one machine. This was more true I think in a 32-bit world then it is nowadays on 64 bits machines that have a lot more RAM.

A multi-instance system would perhaps need a bit more tooling to create and configure the environment such as databases and web application instances. One can argue you need to have this scripted anyhow also for your single instance deployments. Doing this has other perks also like the ability to set up development and testing environments

I would leave the tenant capabilities out until you can make a case for it (engineering cost vs money saved on (hardware) infrastructure through process sharing).