Comparisons based on multitenant architecture

With the differentiation in level sets of application and database in a multitenant architecture, as follows:

AD- a dedicated application server is running for each tenant, and therefore, each tenant receives a dedicated application instance.

AS – a single application server is running for multiple tenants and each tenant receives a dedicated application instance.

AI – a single application server is running for multiple tenants and a single application instance is running for multiple tenants.

DD – a dedicated database server is running for each tenant and therefore the database is also isolated.

DS – a single database server is running for multiple tenants and each tenant gets an isolated database.

DB – a single database server and a single database is being used for multiple tenants

DC – a single database server is running for multiple tenants and data from multiple tenants is stored in a single database and in a single set of tables with same database schema, but separation based on records.

this part of my book now focuses on the comparisons and rules of thumb that can be drawn from the pairwise combinations of the above application and database variations. The consequences of the choices and the selection of subsets of patterns then becomes easier for software architectures. The highest level of sharing with (AI,DC) shows that time behavior, recoverability, confidentiality, diverse SLA and software complexity suffers the most and with the opposite end of the spectrum of (AD,DD) they improve the most. The converse is also available to see with other sets of criteria from the seventeen listed earlier. Resource utilization, number of tenants, maintainability, deployment time, and monitoring improve significantly with (AI, DC) while they suffer on (AD, DD).

This kind of comparisons-based matrix can be drawn out in detail and it helps to formulate rules of thumb as follows:

1.       Focus on the database dimension – The effect of different architectures on decision criteria is largest on the database dimension. Focusing on database first before application for multitenancy.

2.       Sharing database tables enables serving of many tenants but harms robustness – an architecture in which the database schema is shared is beneficial if there are many tenants and end-users, but variability suffers, and unintentional sharing occurs

3.       Sharing application instances help maintainability and performance but harms variability           - Decision makers can decide to share the application instance between tenants.

4.       Ease of implementing variability differs greatly per architecture model. In fact, variability has the highest distinction factor because variability and sharing are contradicting to each other.

Dedicated servers improve performance and variability but hamper scalability. The recovery, variability, and confidentiality are better on dedicated infrastructure. The scalability suffers due to costs.