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 ?)
Don't put all the authentication data in the shared database.
Instead of storing tenant identity and authentication details in a separate database, you can store identity (username) and redirection details (server/instance.databasename). Then you can handle authentication at the tenant's database.
I'm assuming admins are going to send invitations to their users. All of the account information is predominantly handled in their own database. Just use the identification and redirection database to help in managing duplicate usernames. When a new account is created, you just need to create a record here with the database identify information (This should be part of the create user transaction.). There isn't anything highly sensitive in this shared part of your data. You could probably redirect a tenant to a specific application server as well. Internally, if you move a database (Maybe a huge client gets their own server.), just change the redirect records.
Salesforce.com doesn't allow duplicate user names across their entire system, so you should be able to do it as well.
Best Answer
Bottom Line Up Front: You will likely have to start with a compromise.
Micro-services, and multi-tenancy are hard. You have to consider the trade-offs on cost to run, maintain, and build your solutions. The answers are going to conflict with what makes the system more robust and secure. The challenge is to figure out where your project needs to start, and what compromises you have to accept for the moment.
There are a couple axioms to keep in mind:
When you start breaking down the different topics, you are going to find that what is more correct for one answer is less correct for another. For example, your first topic and your second topic have different answers.
Maintainability
One thing is easier to maintain than several things. That goes even more for your database.
Having one large shared database cluster is going to be easier to manage the following:
At least they will up to a point. The problem you may get to is that one of your application's tenants has vastly more demands than another. If your database is a shared resource between the tenants, you will eventually run into the situation where your super users are impacting your service to the other tenants. That may not be something you have to worry about on day one.
Impact of Disasters
If your database goes down, you will need to restore the database server then restore the latest backup.
It's worth looking in to databases that are designed to scale out. Examples would be Apache Cassandra, Mongo DB, Raven DB, etc. Most NoSQL databases are designed around this concept. The upshot is that you have one "logical" database, but multiple processing nodes allow you to expand capacity as you need. It might be a worthwhile compromise to simplify your data design while having the robustness and safety you need.
Feasibility of multi-tenant database approach
That's something you'll have to evaluate. The approaches you are weighing against each other are:
To perform a useful analysis of alternatives, you need to define:
Create the chart, see how each approach hits those check marks, and then make a decision. Remember the axiom about complexity and cost being directly related? The decision you have to make right now may not be what the pundits say is the most correct thing. You have to live within budget constraints. As your application brings in more revenue, your budget will increase, which will allow you to update your system in ways you can't consider right now.
Security
Security is a complicated topic, that has so many facets that again you have to make decisions based on the real legal requirements you have in your country, or that your clients demand. Below are a just a few security related concepts:
There is even more than that. Many security aspects will be constant across your alternatives (like encryption, infrastructure security, etc.) However, the answer to the concept of data protection is more secure if your database does not have data from multiple tenants inside of it. That may not matter if the user can't access the database directly.
When dealing with security concerns, it's best to understand what you are actually required to handle:
Even when you consider user privacy laws, the security demands of a bank or health care system are going to be much greater than those needed for a social networking app.
Summary
Your team (manager included) need to define the following:
Without those, you won't be able to settle on something that fits the unique demands of your application. The most correct thing is going to a bit different for each application because the unique requirements and constraints you have to work with influence what that actually is.