Multitenancy Options on Azure

Multi tenancy Options on AzureHimanshu DesaiPrincipal Consultant & Technical Specialist1

Page / Copyright ©2014 by Readify Pty Ltd2

Agenda› General Architecture› Concerns when developing for cloud› Single vs Multi-tenancy› Recommended approach

Developing for Cloud


Developing for Cloud Concerns ….› Backup and restore policy› Monitoring› Resiliency › Physical access to machine

Multi tenancy


Why multi tenancy› Subscription model is easy to develop› Reduce Operating cost› Support more clients with less resources› Create new models for revenue generation

Page / Copyright ©2014 by Readify Pty Ltd7Page

DatabaseEach Tenant gets their own portion of the database based on the primary key

Traditional Multi-tenancy approach

Tenant 1

Tenant 2

Tenant 3


Traditional Single Multi-tenant DB

TenantID PatientName DoctorName Field1 Field2

1 John Dr Cooper Consulted

3 Mark Dr Antonio N/A Yes5 Paul Dr Smith Consult

ed???

3 Tom Dr Bennett N/A Thanks


Problems› Noisy neighbour problem› Everyone must upgrade all the layers at the same time › Big bang – risky› Can not easily export data out

PagePage

Web Browser

JavaScript Applicatio

n

Phone/Tablet

NativeApps

Cloud based Multi tenancy

ASP.NET

Server Code

Web Sites

Request

Response

DB

DB

DB

SQL

Azure


Single vs Multi-Tenant


Important Points› Scaling a single database can be done easily› Fine grain control on upgrade› Less risky – can test a feature on a limited set of clients› Versioning and upgrade is easy› Easy to support› Can easily export data› Expensive compared to single database

SQL Azure (Quick Overview)


DBSQL

DBSQL

DBSQL

App

SQL Azure


Features› Database as a service› Elastic Scale with Sharding*› Predicatable performance› Availability backed by replica and SLA› Data protection via auditing, restore and geo-replication› Self managed› Three replica are running at one time (one primary and two or more

seconday)› Availability in 3 Models: Basic (2GB), Standard (250GB) & Premium (500GB)

› Also introducing Elastic Database (in preview)


Sharding – Why?› The total amount of data is too large to fit within the constraints of a single

database› The transaction throughput of the overall workload exceeds the capabilities

of a single database› Tenants may require physical isolation from each other, so separate

databases are needed for each tenant› Different sections of a database may need to reside in different

geographies for compliance, performance or geopolitical reasons.


Horizontal Vs Vertical Scaling


Challenges› Not everything you do in SQL Standard is supported in SQL Azure› Your database layer must be resilient to failure› We may need to include stories to make it SQL Azure Compliant› What is not supported

› https://msdn.microsoft.com/en-us/library/azure/ee336281.aspx

Recommended approach


Recommended approach› Use Full edition of SQL Server on premise clients› Use SQL Azure in the cloud

› Single tenant is recommended due to existing development› Prefer SQL Basic for really small clients, Standard for other and scale up

as necessary› When developing new SQL Scripts, ensure they are SQL Azure compliant

Multitenancy Options on Azure

Documents

Transcript of Multitenancy Options on Azure