Multi-Tenancy Solutions

Traditional Software On-Demand Utility Build Your Own Plug In, Subscribe Pay-per-Use

Traditional Software as a service Designed for customers to install, manage and maintain. Designed from the outset up for delivery as Internet-based services Architect solutions to be run by an individual company in a dedicated instantiation of the software Designed to run thousands of different customers on a single code Version control & Upgrade Problems Fixing a problem for one customer fixes it for everyone Hardware & Maintenance Costs Use cloud service, manage and customize IT costs

• The vast majority of SaaS solutions are based on a multi-tenant architecture. • With this model, – a single version of the application, – with a single configuration (hardware, network, operating system), – is used for all customers ("tenants"). • To support scalability, the application is installed on multiple machines (called horizontal scaling).

No content

No content

No content

• The TenantId column and separated data stores. – The TenantId is simply adding a column to all the columns, showing what tenant the row belongs to. – The separate data store calls for a much higher level of separation, where there is no shared storage for the tenants.

• Single Database – all tenants in one database • Pros – Ease of implementation – Fast deployment • Cons – Security – Scalability

• Single Database – all tenants in one database

• The TenantId approach allows you to use a single DB for the entire application, potentially reducing costs for managing the environment. • It comes with a whole set of problems, – Isolation: You have to actively do filtering all the time. – Security: you have to let all tenants access the data, security is in the app logic level. – Extensibility: in a shared environment it is hard to do a lot of extensibility in the data, because each client is stepping on each other toes. – Backup

• Isolated Databases – single database per tenant • Pros: – Scalability – Security – Custom schema for tenant – Ease of migration old applications to multitenant approach • Cons: – Uneven distribution of data – Increased required resources – Need of holding second database connection – Difficult deployment and maintenance

• Different environments per tenant • Pros – Dedicated changes for tenants – Handling common changes – Code security • Cons – Deployment process – Maintenance – Changes management

• Code with custom additions • Pros – Easier deployment – Possibility of custom changes • Cons – All of the code in single repository – Bugs in dedicated modules

No content

No content

No content

Scalability Isolation Billing & Costs Customizability Automation Maintainability

• Multi-Tenant Data Architecture http://msdn.microsoft.com/en- us/library/aa479086.aspx • Developing Multi-tenant Applications for the Cloud, 3rd Edition http://msdn.microsoft.com/en-us/library/ff966499.aspx • Berkeley University SaaS presentation http://bit.ly/1qlSQ56 • Database design in SaaS platform http://labs.octivi.com/database-design- in-saas-platforms/ • Multi Tenancy - The Physical Data Model http://ayende.com/blog/3497/multi-tenancy-the-physical-data-model • Development strategies for multitenant platforms http://labs.octivi.com/development-strategies-for-multitenant-platforms/ • Multi Tenancy - Approaches and Applicability http://ayende.com/blog/3530/multi-tenancy-approaches-and- applicability