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 ?)
Yes, that's it. But wikipedia's definition is not general enough. It does not address multi-tier architectures or newer forms of architecture like SOA or microservices.
Multi-tenancy is about software systems and data isolation. Some examples:
- a multi-tier system with a unique database can be multi-tenant. Example: a SAP system is composed of a database backend and a couple of web application servers that expose in a scalable manner web-services. It is multi-tenant: you can add a new customer without changing the running software installation, and several customers can use the system without ever knowing about each other. The data is completely isolated (proprietary technology).
- your system is composed of one or several processes running webservices that are exposed to different customers via different domain names (but it's still the same processes that run it on the server). The data isolation is achieved with separate databases. It's definitively multi-tenant.
- a microservice system could similarly run several loosely coupled sets of webservices, each using an own micro-database. If needed in order to scale up, you could start new clones of the same microservices and they would via some registering feature find their peers and automatically connect to them, offering to the user the behavior of a single application. Then there are two scenarios possible:
- if, when you want to serve a new customer, you have to start a new separate set of microservices, and organize that the microservices for one customer only connect to the microservices relating to the same customer, then it's single-tenant.
- but if you could serve new customers using the running instances (and new microservices would only be needed for performance), then it's multi-tenant
Best Answer
You've misunderstood the article
You've taken "multi-tenant" to mean "an application which is used by more than one tenant". I'm actually on your side here and I interpret multi-tenancy the same way, but the article uses a slightly different definition, which you seem to have missed.
In the article, and I admit I agree they should've pointed this out a bit more explicitly to avoid ambiguity, "multi-tenant" is being used to mean "more than one tenant using the same resource":
Contrast this to the previous paragraph about single-tenancy:
Circling back to your question:
The article doesn't claim that sharing resources is better. But when not sharing resources, the article calls it single-tenancy (B) and not multi-tenancy (A).
Single-database multitenancy
I also want to address your comment on why someone would ever use multi-tenancy (as per the article's definition of multi-tenancy).
If you allow an analogy, I cannot fathom how my parents can buy a $200 desktop and use that for all their computer activities. The desktops I build cost ten times that.
But the simple conclusion here is that not everyone needs the same specs. My parents are not power users or gamers. If they can open word/excel files and browse the internet they're happy because that's all they really need. Spending more on a better desktop would be a waste of resources for them.
Similarly, multi-tenanted applications with a small footprint and no reasonable need to think about scalability don't need a multi-database setup. Spending more time, effort and complexity on implementing it anyway is just a waste of resources.
"Better" is a very vague criterium. You intend it to mean "more robust and scalable", but you're glossing over the fact that it also costs extra time and effort. If you don't need the robustness and scalability, then using it is just a waste of resources, which means it's not "better" for your particular scenario.