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.
Integration -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
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
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
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
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
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
Maturity Model
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 .
Comments (0)