Criteria for evaluating multitenant architecture:

 

The right choices for multitenant architecture are difficult even for software architects. Bad choices result in poor performance, low scalability, limited flexibility, and obstruct software evolution. architecture patterns are compared to support decision making but the rigor to compare the models falls short because a list of comprehensive criteria is often overlooked.

This part of my book focuses on the criteria to evaluate multitenant architectural patterns. There are seventeen of them. They are quantifiable attributes that can help differentiate one model from another. Although Application and Database are the most frequently referred to layers for multitenancy, there are in fact several more. These criteria can evaluate differences within these layers.

These criteria include:

1.       Time Behavior - an architecture where the tenant sees a perceptible difference between a single application server running for multiple tenants and a dedicated application server for each tenant highlights this criterion.

2.       Resource utilization – The solution provider must pass on the bill to the tenant and there is little justification for underutilized resources. Higher density can improve resource utilization.

3.       Throughput – This criterion helps with the traffic served even if the utilization of the resources is similar.

4.       Number of tenants – An architecture that supports a higher number of tenants is better prepared for cost efficient scalability than others.

5.       Number of end-users – Tenants may vary in the number of users they support so a criterion must separately measure the number of end-users.

6.       Availability – High availability is not just a design criterion for the SLA given to tenants but also the infrastructure concern for maintaining it in the long run.

7.       Recoverability – Certain faults do occur from time to time. Recoverability is a measure of whether the mean time between failures is low or not. Given a Boolean up or down value over a timeline, the difference between a down from an up must be averaged out and brought to a small value when an architectural model exhibits recoverability.

8.       Confidentiality – Data isolation and protection cannot be covered by any one criterion but this one help to ensure that a system with high confidentiality can guarantee that for tenants.

9.       Integrity – If the system or the data can be compromised by virtue of sharing the resources, then architectural models differ on this criterion.

10.   Authenticity – In a dedicated model, there is little, or no intervention or handling of the data and the tampering of the model is affected.

11.   Maintainability – A dedicated system can be considered simple, but it is must more costly to maintain than those that involve sharing

12.   Portability – A dedicated system might have high portability, but it also depends on its technology stack.

13.   Deployment time – This has a business value for the tenants and can vary between systems that require rigorous repeated creation versus instantiation.

14.   Variability – An architecture where the variations are huge between tenants indicates that the infrastructure is not able to address some of the customer requirements.

15.   Diverse SLA – SLA is not just about availability and duration; it involves many factors. A dedicated system might be best equipped to provide high SLA.

16.   Software complexity – The lighter the software the heavier the resources and vice versa. This criteria measures complexity

17.   Monitoring – There are many components that can be monitored but monitoring is a criterion by which different architectures can differentiate from one another.

#codingexercise

https://ideone.com/mIKj1i