Multi-Tenancy Design Consideration

Anandhi KAssociate Director
CERTIFIED EXPERT
Published:
In this article, we will see the basic design consideration while designing a Multi-tenant web application in a simple manner. Though, many frameworks are available in the market to develop a multi - tenant application, but do they provide data, code portability, maintainability and platform agnosti

Background


A multi-tenant application is a software where a shared code base installed on a single instance/pool serves 1…N client / tenants.  Designing a Multi-tenant application really needs a huge effort for handling all complexities from data security to UI display.

Consideration points at high level


  • Externalize
    • Data Store
    • Integration
    • External Communications
  • Flexibility
    • Customization through Configuration
    • Customization
  • SAAS Delivery Consideration
    • Way of Hosting
    • Maturity Model
    • Cloud Deployment Consideration

Externalize


Externalizing a component/feature provides an increased agile operation. Main application can more easily adapt to any changes in external component, along with various other benefits of the base application
Data Store
Any persistent repository for storing collections of data, such as a database, Cache, a file system or a directory is a data store. We can see the design consideration for the presented below data store items Securing the private information of one tenant from the account of another has to be ensured in storing the data.
DataStore.jpgIntegration -Dependency Injection / Inversion of Control

Component and Service 

  • Loose Coupling provides agility and flexibility to operate independently of each other with no problems.
Dependency Injection and IoC container
  • Passing a dependency (a service) to a dependent object (a client) is termed as Dependency Injection. In the direct DI, dependencies can become nested and clumsy to connect them up manually. In such cases IoC can be used where container takes care which class/ dependency object to inject into other dependent /class so the injecting control is reversed during the run time.

External Communication


M_Communication.jpgthe transmission of information between a business and another entity in the company's external environment is referred here as external communication. Some of the external communication sectors that need to be externalized are Sending Message(Email, SMS), Log, Audit, Import/Export, Communication templates,
 

Flexibility


M_Flexibility.jpg
Each tenant specific requirements

Extended Attributes/Extra fields


Each tenant can have a special set of data to capture as additional details, Also each business can apply special constraint rules on the data capture and customize the words of display according to their organization standards. In existing system, there may not be a field available to capture that detail. There should be provision to configure extra fields for each tenant without affecting existing application.

Dynamic Validation


 XXX Client says that in Customer Module, the Customer code should be of length two (2) While YYY Client says code should be of length five (5).

How to implement this in single codebase?

Fluent Validation API can be used to enable dynamic Validation


White-Labeling

One Tenant may like to display  a field as Customer Name while another Tenant like to display that same field as Cust. Name in their site. White labeling comes for help.

Customization & Configuration

M_CC.jpg

Customization


Altering features developed in open standards, with specific intentions in mind (innovative) to create or maintain their Organization culture or identity or need. Some of the items of customization are listed below

In18.jpg
Configuration (Customization through configuration)

The system has to allow the tenant company’s system administrators to configure and customize the site/ application that their end users see. Presented below are some of the common configurable items

Meta Data – Configuration



Security – Considerations​
M_Federate_Authen.jpgsecurity.jpg

SAAS Delivery Consideration   


Deployment Model

  • Approach 1: Separate Instance and separate Database for each tenant.
  • Approach 2:Same single Instance & separate Database for each tenant.
  • Approach 3:Shared single Instance & single Database but separate schema for each tenant.
  • Approach 4: Shared single Instance & Shared Database, Schema for all tenant
M_Deploy.jpgMaturity Model




Model.jpg



Generic basic qualities to be considered


  • Scalability and Concurrency :
    • Necessary user and session data can be stored either on the client browser, or in a distributed store – Distributed cache that's accessible to any application instance. Stateless makes it easy to scale.
    • The necessary context data can be moved to distribute-server configured for cache
    • Concurrency (easy to scale) can be maximized by minimizing exclusive read-lock for operations on resource (Data store-DB, Cache, Log). 
    • Componentization provide more scalability 
    • Cache can be clustered to scale easily  
  • Metering and Monitoring: Pre and Post Method hooks can be provided in the exposed API’s to capture the call Usage. At base point integrate the Metering API to enable it across the application  like
    • OnActivityStart Event
    • OnActivityEnd Event

Conclusion


This article can help you in designing and design review of your multi-tenancy supported site .
0
1,002 Views
Anandhi KAssociate Director
CERTIFIED EXPERT

Comments (0)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.