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.