I had a discussion with Iris Classon back in February, 2016 regarding this concept, where I threatened I would start blogging, expressing to everyone that which she and I were discussing in private. Well, three years later and I am finally living up to the promise I made to her.
For me, I started development of a multi-tenant solution in 2012 when I partnered with another person in the point-of-sale industry to develop our own cloud-enabled point-of-sale for restaurants. This other person approached me about doing this, and after much turmoil, I accepted the offer and off we went.
I spent the better part of three months reading others articles, examples, sample source code, etc. to come up with a personal opinion of what a multi-tenant solution would be for me. Most of the concepts that will be presented are an aggregation of reading other’s code and blog posts, and for that, if I could credit each and every other software author, I would. In sort, to those that have authored similar posts with these concepts… I sincerely thank you.
Microsoft documents three styles of multi-tenant architecture:
With a standalone application, you are writing an application without the concept of multi-tenancy, and you emulate the idea of multi-tenancy by hosting each client’s deployment on a dedicated host, but the entire stack, from web through database is an isolated ecosystem. For less than ten (10) clients, this is very acceptable, as it is quite easy to manage deployments, and keeps each tenant rather stable; you get to choose when each client is upgraded.
With a shared multi-tenant application, this is your next iteration of sophistication. The basic concept here is that you enhance your data model(s) where each model is tagged wtih a company or account identifier, and then you scope the rest of your system with associated queries to limit each result set so that only those items from the client’s company or account identifier are returned.
This form of mutli-tenancy offers the same simplicity of a standalone application (as you have one application and one database, in most circumstance) but provides the ability of supporting many clients within the single application. Deployment is similar to a standalone application (only one physical solution to deploy, one database to update) but provides an advantage over the standalone application as you can quickly add additional companies or accounts with limited overhead. This form of multi-tenancy is preferred for most products, as it is simple to setup and maintain. For most systems, this will scale well, as the amount of data per-tenant is rather small, and when the number of accounts grow, the overhead cost of adding each account gets amortized very quickly.
With a database per-tenant architecture, you get a blend of a standalone application, in that your queries do not require you to filter each query by its company/account identifier; the sophistication of an ability of only needing to deploy a single application, and the scalability in that for larger scales of data, you can change the settings of the database to allocate or de-allocate resources for that client.
With this architecture, you arrive at having n+1 databases, with the +1 application being the management data for the entire application, and each of the databases being one for each client.
We chose to use the database per-tenant architecture. We had several reasons for this choice:
An aside before we move on: Think seriously before adopting the database per-tenant approach. Although we thought that this would be the best method (and it may have been), we invested countless hours into research and development of this exact topic. Should we have adopted the multi-tenant database approach, we could have more easily focused on our core business logic and factored to a database per-tenant after the fact, if and when we determined that it would be more cost-effective to do so.
Over the next few posts, the focus will be to explain how the solution has been architect-ed to be developed as it was. Each post will cover one aspect of bringing this online.