Click here to Skip to main content
15,886,873 members
Articles
(untagged)

Multi-Tenancy Design Consideration

Rate me:
Please Sign up or sign in to vote.
4.83/5 (13 votes)
6 Oct 2014BSD8 min read 39.8K   28  
The basic design consideration for a Multi-tenant web application

Introduction

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 agnostic support? The answer is doubtful.

Background

A multi-tenant application is a software where a shared code base installed on a single instance/pool serves 1…N client / tenants

Architecting or 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.

Database
Designing Database The approach can be decided with trade-off between performance and security.
  • Approach: 1 – Different database with similar schema definition
  • Approach: 2 – Shared database with multiple (similar) schemas
  • Approach: 3- Shared tables in same schema
Image 1
Defining data model 
  • Common Data (Reference data, Metadata) that are generic across  all tenants

  • Tenant specific Common Data (Reference data, Metadata, Masterdata) that are specific to a tenants’ users (e.g. Master data ,lookup values/Pick list management,Search management,Configured/Extended new fields /columns data)

  • Each tenant’s transactional data
  • Tenant provision data for vendor (e.g.Configuration details,Tenant profile, and provision details

Image 2

Security & Compliance of data 

  • Tenant specific can be isolated to avoid data proliferation across client instances.
  • Encrypt data for security purpose

Back-Up & recovery of the data at ease of operation cost 

  • Taking data while moving from current SaaS Vendor to another, the design should allow to continue the application with the transactional data and without applications common data. Design has to support running the system on premise.
Cache
  • Cache server can be clustered. 
  • Data can be isolated at Tenant level (But access  with similar queries)
  • Partial data Refresh/Reload can be enabled to provide uninterrupted data store to other tenants data in cache. 
  • Client side session store can be configured to remote cache server. 
  • Scenario to consider Due to some failover a server change is required. How does the cache server get changed without affecting the application?

    Clustering can help in failover situation.

  • Can it be scaled out with no code change in application?

    Data Isolation at Tenant level (But access with similar queries) provides the ability to scale easily.

Integration -Dependency Injection / Inversion of Control

Image 3

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

Image 4

The 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

Image 5

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

Image 6

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

  • Internationalization
  • Personalization
  • Extending the UI fields
  • Search Filter /Display
  • UI –WebParts

 

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

Process Area

Detail Description

Configurable items

Functional Logical Unit  Configure the code developed
  • Functional Modules/Components,
    • Example : User Management, Order Management , Document Management
    • Refer the order of dependent Modules
    • Version of the service
  • Module’s/Component’s Feature,
  • Feature Operation (Add/Edit/Delete),
  • Feature Attributes and so on into the system
Work Flow

Workflow differs for tenants.

  • Actions/Activity,
  • Rules/Conditions,
  • Actor,
  • Status –
  • Associate Action and Condition upon which actor should act on should be configurable
  • Map the pre and post status on action
Business Process Flow

Standard systems like ERP, CRM, and Ecommerce have set of predefined process

  • Predefined process
  • Choreograph the predefined set of process
  • orchestrate the business process flows according to organization or tenant business needs
Batch Process

Any batch process and job

  • Parameter
  • Batch process mapping to tenant
Scheduler

The scheduler has to be available in the system to schedule the Batch process /Job to execute in periodic intervals.

  • Frequency
  • Duration
  • Parameter
  • Job/batch process
User Experience

Internationalization & Localization.

  • Tenant Level Localization
  • User level Localization
  • Multilingual text for static content

Security – Considerations

Image 7

Authorization
  • The system has to provide a fine set of  granular level  access control security
  • Access Control Matrix has to be configurable in the application
  • All tenant organization structure won’t be alike so need not stick to RBAC
    • User group segregation (role can one among them): who can access.
    • Function logical unit (like modules, module features, feature activity [CRUD, I/O and so on], feature attributes, feature page, and feature Controls): what can be accessed.
    • Permission levels (No-access, Read, Write, and Read-Write]: which permission is allowed. 3W combinations can form Access Control Matrix
Authentication & Federated Security
  • The system has to support  multiple authentication mechanism like email, userID/Password in LDAP, Database, OpenID access
  • It can allow to choose single or multiple authentication mechanism.
  • It can have provision to support single factor, multi-factor or crypto-factor
  • It can allow to configure multiple authentication mechanism for a single tenant. There might be chances of having Hired/Contract employees/augmentation support people working in a company who won’t be part of their User Management System. To provide access rights to this user using some other Authentication mechanism
  • Federated Claim-based authentication can be used for custom authentication
Data Security Message Security
  • Isolation of data from one Tenant Company to the next.
  • Encryption of Data

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

Image 8

Maturity Model

Model Name

Instance Type

Customization type

Ad-Hoc

One individual instance for each client

own customized version of application

Configurable

One individual instance for each client but with same shared code base used for all

Individually customized (with configuration)

Configurable [Model 2] + Multi-tenant Efficient

Single instance that serves every customer

Configurable meta data provide a unique user experience and feature set for each tenant

Scalable + (Configurable & Multi-tenant Efficient ) [Model 3]

Identical instances on load-balancer to server multiple customer

Each tenant’s data kept separate, and with configurable meta data providing a unique user experience and feature set for each customer.

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 .

License

This article, along with any associated source code and files, is licensed under The BSD License


Written By
Architect
India India
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.

Comments and Discussions

 
-- There are no messages in this forum --