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.

Levels in multitenant architecture

Although Application and Database are the most frequently referred to layers for multitenancy, there are in fact several more. The right choices for multitenant architecture depend on the considerations at all these levels. Evaluation of the viability of an architecture pattern for multitenancy can be based on a list of comprehensive criteria that is drawn from all these levels.

This part of my book focuses on the levels of the multitenant architecture and the comparisons of the criteria. There were references to seventeen criteria earlier that included Time Behavior, Resource Utilization, Throughput, Number of tenants, Number of end-users, Availability, Recoverability, Confidentiality, Integrity, Authenticity, Maintainability, Portability, Deployment Time, Variability, Diverse SLA, Software complexity and Monitoring. All of these are quantifiable attributes that can help differentiate one model from another. These criteria can evaluate differences within these layers.

 A stack of different levels from top to bottom would include Hardware, Virtual Machine, Operating System, Database Server, Database, Database Schema, Middleware, Application Server, and Application Instance. When multitenancy is applied at a specific level, the levels below that level are shared among the tenants. Isolation occurs at the levels above that level.

Even when tenants are consolidated in a single database, each tenant can operate on isolated set of tables with proper naming conventions. In a schema-level, isolation occurs at row-level of table. Conceptually, it is easy to differentiate between the levels as Application related layer set and Data related layer set. Within each of these layer sets, it is possible to segregate ascending levels of sharing. With the help of following notations, it is easy to compare multitenant architectures:

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.

Similarly, for the data related layer set:

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.

Some common occurrences of Multitenant architectures include the following pairs from the application and the data related layer sets: (AD, DD), (AS, DD), (AI, DD), (AD, DS), (AS, DS), (AI, DS), (AD, DB), (AS, DB), (AI, DB), (AD, DC), (AS, DC), (AI, DC)

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

 

Re-engineering of multitenant applications 

 

This part of the book focuses on the challenges of reengineering into multi-tenant SaaS applications.

SaaS is a business model where companies can do away with their proprietary infrastructure.  Their subscription to the solution provider requires only internet access to use the services. This architectural pattern requires a single instance of a software that continues to work for different tenants not in a multi-user mode but one where tenants can bring their own customizations.

Multitenancy is about sharing provisioned resources for customers. It is often explained as: 

virtualization + resource sharing = multi-tenancy 

Tenancy is about customers not users. Multiple users from a single organization can form a single tenant. Examples of multi-tenant applications include Business-to-Business solutions, Business-to-Consumer solutions, and Enterprise-wide platform solutions. 

A set of requirements must be drawn before a single-tenant application can be converted into a multi-tenant application.  These can be enumerated on a component-by-component basis.

First, the authentication layer must support membership directories for the tenants. Let us take an example of an authentication layer as comprising of a ticket generation mechanism and an authentication module. The Kerberos ticket issuing web service has enough information in the tickets to allow tenant identification throughout the application without requiring continuous calls to the service. It is also possible to add extra information to the ticket when necessary. The authentication module, when implemented as an ASP.Net HTTP module verifies whether every request comes from a valid tenant otherwise a login screen is displayed.

Second, the configuration library could consist of a layout component, a general configuration component, and a file I/O component. In this case, the layout component loads a tenant specific master page. The general configuration is a library that must be integrated with the portal source code. The file I/O is a cross cutting concern and is tedious because source might use various constructs for file I/O.

Third, the database layer could comprise of a store or a custom library that is integrated into the portal code. The query adapter can augment the tenant predicate to the queries.

From these requirements, it must become clear that a conceptual reengineering approach is required to support the process. This approach must consider scalability, configurability, version support, completeness, support for different applications and threats to validity.

Scalability is facilitated by introducing little or no computational overhead even from cross cutting concerns or it could require an implementation of a standalone service. Although databases are designed to be extremely efficient, their usages make them performance bottlenecks in several cases. Use of a load balancer and a database pool mitigates this. This still does not take into account the scalability of the single-tenant’s business logic.

Configuration requirements depend heavily on the type and implementation of the application. It is, however, a key aspect of most applications and therefore one that must be part of the approach.

Version support cannot be an after thought after the first release. It must an essential feature in the design of the multi-tenant application.

Completeness can be facilitated with extensions to single-tenancy and it also involves validation and testing that must be specific.

Finally, even if the multi-tenant application is written from scratch, these concepts must be factored into the design prior to its release.

A new security attack vector on multitenant solutions

Multitenancy is about sharing provisioned resources for customers. It is often explained as: 

virtualization + resource sharing = multi-tenancy 

Tenancy is about customers not users. Multiple users from a single organization can form a single tenant. Examples of multi-tenant applications include Business-to-Business solutions, Business-to-Consumer solutions, and Enterprise-wide platform solutions. 

One of the ways to manage resources is resource governance. Resource governance is hierarchical in nature. From top to bottom, limits can be enforced at various levels using their level-appropriate mechanisms starting with the operating systems, then the resource pools and the workload groups. Data I/O governance limits both the read and the write physical I/O against persisted data. IOPS limits are set for each service level to minimize the noisy neighbor effect. 

While noisy neighbors are a common scenario, it is not an attack vector. Those are determined based on threat model. A common methodology to study threats is STRIDE analysis and threat mitigation. It is an acronym for the following: Spoofing Identity – is the threat when a user can impersonate another user. Tampering with data- is the threat when a user can access Kubernetes resources or modify the contents of security artifacts. Repudiation – is the threat when a user can perform an illegal action that the Kubernetes cannot deter. Information Disclosure – is the threat when, say a guest user can access resources as if the guest was the owner. Denial of service – is the threat when say a crucial component in the operations of the Kubernetes is overwhelmed by requests so that others experience outage. Elevation of privilege – is the threat when the user has gained access to the components within the trust boundary and the system is therefore compromised. 

One of the unique threats posed to multitenant solutions is that the attacker and the victim can share the same server. Such a setup cannot be mitigated by traditional security measures. When the attacker and the victim are in the same provider but located on separate servers, the attack vector is only penetrating the virtualization layer. When they are collocated, the attack vector is penetrating resource sharing. Traditional network security fails to provide adequate protection in this regard. 

Consider the case when an attacker begins the attack with network probing and follows it up with a brute force attack to take advantage of the multitenancy effect by allocating the attacker’s virtual machine besides the victim’s virtual machine. When this is achieved, a side channel attack can take advantage of system characteristics with which the attacker extracts the data of the victims. Hypervisor and operating systems do not help mitigate this adequately. 

Potential mitigations of this attack vector include the case where a resource allocation technique is employed that determines the location of resources randomly. Another way to provide mitigation to select tenants could be to restrict the number of usages of those resources. In these cases, the attackers’ cost, effort, and time are dramatically increased. 

Not all multitenant solutions need to focus on such advanced mitigations. With proper network security at higher levels, these attacks not only become rare, but they become insignificant to mitigate. East-West network security is often planned for with the security compliance efforts of the multitenant solution provider. 

#codingexercise

https://ideone.com/TTu3xF

The multi-tenant Frontend case study with ASP.Net stack

 

This part of my book delves into an example of writing an ASP.Net Application with multi-tenancy. One of the very common asks is for an application to be made available in a different appearance for another business in the parent organization’s portfolio. Occasionally, this business might have its own active directory domain and missing federation. 

The choice of technology stack only affects the development of the software since multi-tenancy is an architectural decision. If they were different applications for each business, they could implement independent technology stacks regardless of whether the data provider services, and store are common to the businesses. When there is a user interface involved, the technology stack leans towards write-once-run-anywhere paradigm. ASP.Net fits this bill very well because it separates the client and the server code very well. The client code can be developed to suit all platforms – mobile, web, native mobile and native desktop. Web workers and server-side rendering makes it super-fast and bring security and performance to the server. Finally, ASP.Net is developer friendly in that it has simple constructs for model-view-controller and templates can be used in views. This makes it easy to get functionality right out of the box and spend less time making code work. 

The switch between single tenancy to multi-tenancy is handled by a few components within an ASP.Net application. First, there is a request interceptor that sets the appropriate tenant in the context. Second, this must be communicated to the server part of the application. Finally, the tenant-based customizations, automatic injection of services specific to the tenant domain, and reconfiguration of routes and redirects as per the domain of the tenant and a few other features must be enabled. 

The URLs for the tenant-specific domain name hosted services usually follow a pattern that can be made well-known across the application code base so that the same code works for every tenant. If the pattern and the whitelisting must be avoided, the tenant information can be persisted and looked up as an alternative from a tenant registry. ASP.Net defines an ApplicationDBContext and a service so these are added to the service. 

Then there will be methods provided for each of the following in the service: translation of the hostname/domain name to the tenant, adding a tenant information specifying header to the set of headers on the incoming request and defining enumerations of the tenants if the resolution is based on pattern and literal matching. 

The server side of the application will resolve multi-tenancy and inject custom services based on different database contexts. The extensions serve this purpose. It must resolve the connection string based on the domain name of the tenant. The connection string is passed to the ApplicationDBContext and a custom service for that domain is then added to the Service collections. A dedicated service, say one for logins, will be created for the tenant to target Active Directory and the domains can be maintained independently for each tenant within the same Active Directory instance.

The login service cannot typically be injected directly like the custom service for the custom DB context in the server startup code. Instead, the AddDefaultIdentity method is invoked on the service collection and supplied with the default user interface and entity framework store.  Similarly, the service collection must be initialized with a pattern for the controller and view resolutions such as with MVC.

The multi-tenant Frontend case study

 This part of my upcoming book delves into an example of writing an Angular Application with multi-tenancy. One of the very common asks is for an application to be made available in a different appearance for another business in the parent organization’s portfolio. Occasionally, this business might have its own active directory domain and missing federation.

The choice of technology stack only affects the development of the software since multi-tenancy is an architectural decision. If they were different applications for each business, they could implement independent technology stacks regardless of whether the data provider services, and store are common to the businesses. When there is a user interface involved, the technology stack leans towards write-once-run-anywhere paradigm. Angular JS fits this bill very well. It can be developed across all platforms – mobile, web, native mobile and native desktop. Web workers and server-side rendering makes it super-fast and offloads the data model building to push-model frameworks like Immutable.js. Finally, Angular is developer friendly in that it has simple declarative templates and the language for templates can be extended. This makes it easy to get functionality right out of the box and spend less time making code work. Google uses Angular for some of its largest applications.

The switch between single tenancy to multi-tenancy is handled by a few components within an Angular application. First, there is a request interceptor that sets the appropriate tenant in the context. Second, this must be communicated to the server part of the application. Finally, the tenant-based customizations, automatic injection of services specific to the tenant domain, and reconfiguration of routes and redirects as per the domain of the tenant and a few other features must be enabled.

The URLs for the tenant-specific domain name hosted services usually follow a pattern that can be made well-known across the application code base so that the same code works for every tenant. If the pattern and the whitelisting must be avoided, the tenant information can be persisted and looked up as an alternative from a tenant registry. Angular defines a module and a service so these are added to the service.

Then there will be methods provided for each of the following in the service: translation of the hostname/domain name to the tenant, adding a tenant information specifying header to the set of headers on the incoming request and defining enumerations of the tenants if the resolution is based on pattern and literal matching.

The server side of the application will resolve multi-tenancy and inject different services based on the resolution. The interceptor serves this purpose. It must be registered with the module. The service itself, say one dedicated to logins, will have separate instances for the tenant so that they can target different membership providers like the Active Directory. There can be some efficiency with a base class and deriving the independent service implementations. Angular applications require that this be defined in module and within the module, when the provider is configured, a factory can be configured that gets the correct instance of the service.

The login service cannot typically be injected directly as an @Injectable but the use of a factory allows us to refer to the correct instance of the service. The module definition must be updated with the login module. Lastly, there must be switching between the routes based on the tenant service in the login module.