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
No comments:
Post a Comment