This document discusses multi-tenancy in software as a service applications using the MVC3 framework and Entity Framework. It defines tenants as users who occupy rented space in a application. It describes how multi-tenant applications like Highrise, Jira and Yay isolate user data while providing each tenant their own interface. The key aspect is the data architecture, which can be separate databases for each tenant, separate schemas within a shared database, or a shared schema. The best approach depends on factors like cost, security, tenant needs and development skills. The document presents an architecture used by YayCRM that supports all these data approaches through a centralized metadata database and tenant databases that can be distributed, expanded or tenants moved between databases.

1. Multi-tenancy with MVC3
and Entity Framework
-By Lasantha Bandara

2. What is a Tenant?
 Literally
“A person who occupies land or property
rented from a landlord”

3. Is there any better example
than Exilesoft…?

4. Is there any better example
than Exilesoft…?
Moota

5. Is there any better example
than Exilesoft…?
Moota
Pro-Account

6. They are Tenants of Exilesoft…
Moota
Pro-Account

7. Same situation applies to the cloud
based software applications.
 In
SaaS (Software as a Service) Model
 Most of the web applications are SaaS – But not
Multi-Tenant…!
 Multi-Tenant Examples,
 Highrise
 Jira
 YaY
 In these systems, organizations make their
accounts and they are provided a look and feel
of their own „Home‟

8. Why this is so important?
 Data is vital for some businesses.
 Should be able to isolate data among
tenants in SaaS model.
 If
we provide it…. We have Competitive
Advantage.

9. That implies…
Data Architecture is the most
significant factor in a Multi
Tenant Application.

10. We can identify 3 different
architectures at present…
 Separate DB – Separate Schema
 Shared DB – Separate Schema
 Shared DB – Shared Schema

11. Separate DB – Separate Schema
 Extendibilitywith tenant specific requirements
 Easy Backup
 High Cost
 Suitable for Medical and Banking applications in
spite of high cost

12. Shared DB – Separate Schema
 Separate set of tables for each tenant in same
DB
 Extendible and easy to implement
 Suitable if No. of Tenants < 100
 Low cost than the previous one

13. Shared DB – Shared Schema
 Lowest Cost
 Additional development effort
 Less security
 Each row contains tenant Id
 Suitable for a huge cluster of tiny tenants

14. Choosing an approach
 Cost Based

15. Security
Shared Isolated

16. Tenant Attributes

17.  Regularity Consideration
(legal requirements of companies)
 Skills set of development team
etc…

18.  InYayCRM we have invented a model
that is supported all those architectures
 You can,
- distribute databases in a server farm
- expand and shrink the number of
databases
- move tenants among databases

19. Metadata Tenant
Database Databases
Client Application
Server

21. Let’s go to demo…