Software As A Service
Multi-Tenancy Architecture Model
Multi-Tenancy Architecture Model
Multi tenancy and SaaS terms are using interchangeably, to represent different point of views for same architecture approach that target providing services for multiple customers on the same architecture and database.
SaaS: software as a service, a new approach that impacts the solution architecture model that enables software organizations to build solutions that serve more customers instead of one customer, which improves their pricing model, and moves from license to rent the solution as a service, using architecture techniques for both SW and HW.
The opposite graph shows the difference between traditional computing and cloud computing, the base for SaaS.
So, Multi tenancy means:
shared services and resources: which include Compute, network, and storage
For multiple customers
Software Companies:
Cost
Higher Cost
Revenue
Competitive price
Higher revenue
Customer Perspectives:
Zero fixed cost
Lower operation cost
Fast kick-off
Zero software license
Customer Perspectives:
Zero fixed cost
Lower operation cost
Fast kick-off
Zero software license
Business Continuity
Core Supportive Modules for SaaS solutions
Moreover the core business modules of your solution, you will need the following core supportive modules:
Solution provisioning tool
Sizing/meters and Pricing module
Configuration module
CRM models
Quality and Governance models
Workflow
Chatbots
Call Center
Documentation models
Import/Exporter modules
Analysis modules
Solution integrator module (SSO,e-Payment,SMS Gateway,OTP)
Open Data Model
AIAS: Artifitial intelegence as a service
We have three architecture models for the database:
Geo-Aware Load Balancer
GeoDes design pattern for deployment:
Replicate solutions
Replicate pipelines
DB Per Geolocation for full isolation
Can serve a single tenant
Can serve multiple tenants
Multi-Tenancy Database Architecture Model
Single Tenant per DB
Multi-Tenant per DB
Provisioning Model
Micro-Services Architecture
AOP implementation approach: For cross cutting aspects
API First Approach: With Versioning Model
DevSecOps
Supportive Modules
Primacy of Cloud design patterns
Primacy of Non-functional requirements
The architecture Model consists of the following elements:
GeoDes deployment model
Same DNS architecture
Geo-Aware Load balancer
Configuration map for different location for full isolation
We have three architecture models for the database:
Database per tenant
Schema per tenant
Shared database
Your application will have a separate database for each tenant, which we can mention the pros and cons as following:
Pros:
Best isolation
High performance
High security
Ease backup
Cons
Expensive
Deployment cost
Low maintainability
Pros:
Better Isolation
Easier maintainability per schema
Cons
Complicated when scaling up to a microservice architecture
Hard deployment process
Pros:
Low cost
Ease of scalability
Added feature for shared tenancies and private tenancies can take place to meet governmental requirements and security policies, for example:
Small entities can live with shared tenants as they focus on cost
The Ministry of Defense needs a dedicated tenant
Cons
Complex Query filtering in shared tenants
Potential data leakage, which impacts security and privacy
Application of a VPD: virtual private database to take place
Use row-level security (RLS) for the shared schema.
Enforce strict tenancy boundaries at the service/API layer.
Design with database provisioning automation for onboarding/offboarding.
Encrypt data at rest and in transit.
Use tenant-aware indexing and sharding if needed.
Apply DevSecOps principles and audit logging.
OWASP practices
DevSecOps
Tenant Isolation: Ensure strict separation between tenants to prevent data leakage.
Access Controls: Implement robust authentication and authorization mechanisms.
Data Protection: Encrypt data at rest and in transit.
Monitoring & Logging: Maintain comprehensive logs and monitor for suspicious activities.
Regular Updates: Keep all components up-to-date to mitigate known vulnerabilities.
Managing requirements for SaaS is totally different from other solutions, which focus on the following principles:
Configure-first requirements
Standard-First compatibility
Customizability features
Non-functional requirements are mandatory
Deployment strategy: will be totally different, with backward compatibility
Autonomous data migration
Requirements challenges for SaaS is totally different from other solutions, which focus on the following principles:
UML-Based requirement management and analysis
White-label solution
Look and feel personalization
Login process
Reporting
Security
Scope:
Requirements
Hot-Fixes
Support
Principles:
Backward compatibility
Configurable
Dynamic implementation
Outage