Multi-Tenancy Architecture Overview

10
i spitfiregroup.com Multi-Tenancy Architecture Overview December 20, 2015 Michael Byrne – Practice Director

Transcript of Multi-Tenancy Architecture Overview

Page 1: Multi-Tenancy Architecture Overview

ispitfiregroup.com

Multi-Tenancy Architecture OverviewDecember 20, 2015Michael Byrne – Practice Director

Page 2: Multi-Tenancy Architecture Overview

ispitfiregroup.com

Multi-Tenancy Architectures

• The word “multi-tenancy” is frequently misused. If you use this word, be specific about what you mean.o Shared everythingo Single Tenant Database

• Shared database – separate schema• Separate databases

o Single Tenant Applicationo Shared Nothing – hosted instance

• https://msdn.microsoft.com/en-us/library/hh534482.aspx

Page 3: Multi-Tenancy Architecture Overview

ispitfiregroup.com

Multi-TenancyShared Everything

• Tenants Shareo Infrastructureo Application Serverso Database

• Proso Cost savingso Data aggregation / data miningo Release Management / Support

• Conso Complexityo Security risks around managing

shared datao Difficult to customize data backup /

restoreo Difficult to limit tenant access to

resources for fair use– This is why SalesForce has governor

limits

Page 4: Multi-Tenancy Architecture Overview

ispitfiregroup.com

Multi-TenancySingle Tenant Separate Schema

• Tenants Shareo Infrastructureo Application Serverso 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

• Conso Complexity of managing separate

security schemaso Cross tenant aggregation is

complexo Tenant administration is more

complex

Page 5: Multi-Tenancy Architecture Overview

ispitfiregroup.com

Multi-TenancySingle TenantSeparate Database

• Tenants Shareo Infrastructureo Application Serverso Database Servers, but each

tenant has a separate database• Pros

o Simple segmentation of datao Simplifies application logico Simplified backup of tenant data

• Conso Complexity of managing many

databaseo Tenant administration is complexo Application servers must

communicate with many databases

Page 6: Multi-Tenancy Architecture Overview

ispitfiregroup.com

Multi-TenancySingle Tenant Application

•Tenants Shareo Database layero 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)

•Conso Complexity of maintenance at

the application levelo Support costs increase

Page 7: Multi-Tenancy Architecture Overview

ispitfiregroup.com

Multi-TenancyShared 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

•Conso No economy of scale for

hardware / licensing / support

o Data aggregation very complex and costly

Page 8: Multi-Tenancy Architecture Overview

ispitfiregroup.com

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.https://msdn.microsoft.com/en-us/library/hh534482.aspx

Page 9: Multi-Tenancy Architecture Overview

ispitfiregroup.com

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 statelesso State consumes memory,

and requires that clients be “sticky” to a node

•Databases should be designed for partitioning

Page 10: Multi-Tenancy Architecture Overview

ispitfiregroup.com

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.