Thursday, August 15, 2019

Multi-tenancy Summarized

Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers (tenants).

Consideration Points:

  1. Quantity of tenants
  2. Performance
  3. Time of development
  4. Reliability
  5. Disaster recovery
  6. Execution Environment Isolation: Adding, modifying or removing features for one customer should not impact other customers
  7. Features added for one customer may be applicable for other customers. Hence customization cannot be tied to a single customer. The architecture should allow same features to be enabled and disabled easily for other customers.
  8. Licenses can be upgraded or downgraded. Features should be grouped so that they can be easily added or removed from a customer execution environment.

Advantages:

  1. Deploy code without affecting other tenants in the environment
  2. Feature Customization: Enable features for a single tenant without disturbing other tenants
  3. Cost-efficient and Financial Benefits
  4. Efficient Resource Usage
  5. Easier Set Up and On-boarding
  6. Easier Upgrades and Maintenance

Disadvantages:

  1. Data Leakage and Reliability
  2. More control over backups and recovery
  3. Migration Ease of Use
  4. Full control over the environment
  5. More vulnerable from a security standpoint
  6. Single point of failure for all Tenants

Approaches:
  1. Separate databases: Each tenant has its own database. Eg. Maintain different databases for different tenants and connect to the correct database at runtime.
  2. Separate schemas: Tenants share common database but each tenant has its own set of tables (schema). Eg: Maintain a single database, but different schemas for different tenants qualified by the Company Id
  3. Shared schema aka Partitioned (discriminator) Data: Tenants share common schema and are distinguished by a tenant discriminator column. Eg: Add a Company Id to all the tables and qualify all queries with a company id.
  4. Data Sharding
  5. Hypervisor-level Isolation

Given the advantages and disadvantages of each approach, I'd recommend using separate schemas, as they provide the best balance between difficulty of development and cost of running the database layer.