Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Multi-Tenancy Architecture Overview


Published on

Overview of 5 models of multi-tenancy (shared everything through shared nothing), corresponding pros and cons, and security concerns.

Published in: Software
  • Be the first to comment

Multi-Tenancy Architecture Overview

  1. 1. Multi-Tenancy Architecture Overview December 20, 2015 Michael Byrne – Practice Director
  2. 2. Multi-Tenancy Architectures • The word “multi-tenancy” is frequently misused. If you use this word, be specific about what you mean. o Shared everything o Single Tenant Database • Shared database – separate schema • Separate databases o Single Tenant Application o Shared Nothing – hosted instance • us/library/hh534482.aspx
  3. 3. Multi-Tenancy Shared Everything •Tenants Share o Infrastructure o Application Servers o Database •Pros o Cost savings o Data aggregation / data mining o Release Management / Support •Cons o Complexity o Security risks around managing shared data o Difficult to customize data backup / restore o Difficult to limit tenant access to resources for fair use – This is why SalesForce has governor limits
  4. 4. Multi-Tenancy Single Tenant Separate Schema •Tenants Share o Infrastructure o Application Servers o Shared database(s), but separate schemas •Pros o Segmentation of data by schema simplifies application logic o Each customer can be assigned the same schema across databases •Cons o Complexity of managing separate security schemas o Cross tenant aggregation is complex o Tenant administration is more complex
  5. 5. Multi-Tenancy Single Tenant Separate Database •Tenants Share o Infrastructure o Application Servers o Database Servers, but each tenant has a separate database •Pros o Simple segmentation of data o Simplifies application logic o Simplified backup of tenant data •Cons o Complexity of managing many database o Tenant administration is complex o Application servers must communicate with many databases
  6. 6. Multi-Tenancy Single Tenant Application •Tenants Share o Database layer o Application layer is isolated by tenant •Pros o Allows simple metering at application layer by tenant o Allows customization of application for tenant • (If you want to support this, using extension points may be a better model) •Cons o Complexity of maintenance at the application level o Support costs increase
  7. 7. Multi-Tenancy Shared Nothing •Tenants Share Nothing •Pros o Each tenant is essentially hosted in their own dedicated environment o Highly customizable by “tenant” o Supports different backup and upgrade options •Cons o No economy of scale for hardware / licensing / support o Data aggregation very complex and costly
  8. 8. Consider Multi-Tenancy Perspective Tenant • Isolation • Availability • Scalability • Costs • Customizability • Regulatory Compliance • Integration (APIs) Provider • Meeting tenant’s goals • Profitability • Billing • Multiple Service Levels (Product differentiation) • Provisioning • Maintainability • Monitoring • Automation • Customer Retention (APIs, support, etc) = Valuation $$ Depending on the engagement we need to see multi-tenancy from different perspectives.
  9. 9. Scalable •Applications should be architected to dynamically scale-out across multiple nodes when a load balancer is put in place •Web applications and services should be stateless o State consumes memory, and requires that clients be “sticky” to a node •Databases should be designed for partitioning
  10. 10. Security • We build solutions that follow security best practices including security-in-depth, claims and role based authorization. • We secure all exposed parts of the application, including UI, APIs, file uploads, etc. • We do not rely exclusively on firewalls and other infrastructure security elements for application security. • We discuss security with our customers.