Software-as-a-Service

Transcript

1. Multi-Tenancy Solutions
2. Traditional Software On-Demand Utility Build Your Own Plug In, Subscribe Pay-per-Use
3. 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
4. • 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).
8. • 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.
9. • Single Database – all tenants in one database • Pros – Ease of implementation – Fast deployment • Cons – Security – Scalability
10. • Single Database – all tenants in one database
11. • 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
12. • 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
13. • Different environments per tenant • Pros – Dedicated changes for tenants – Handling common changes – Code security • Cons – Deployment process – Maintenance – Changes management
14. • Code with custom additions • Pros – Easier deployment – Possibility of custom changes • Cons – All of the code in single repository – Bugs in dedicated modules
18. Scalability Isolation Billing & Costs Customizability Automation Maintainability
19. • 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