New multi-tenant patterns for building SaaS applications on SQL Database
We’re delighted to announce the availability of an expanded set of sample SaaS applications, each using a different database tenancy model on SQL Database. Each sample includes a series of management scripts and tutorials to help you jump start your own SaaS app project. These samples demonstrate a range of SaaS-focused designs and management patterns that can accelerate SaaS application development on SQL Database.
This is an expansion of the sample Wingtip SaaS application launched earlier this year.
SQL Database SaaS app patterns
The same Wingtip Tickets application is implemented in each of the samples. The app is a simple event listing and ticketing SaaS app, where each venue is a tenant with events, ticket prices, customers, and ticket sales. The app, together with the management scripts and tutorials, showcases an end-to-end SaaS scenario. This includes provisioning tenants, monitoring and managing performance, schema management, and cross-tenant reporting and analytics, all at scale.
The three samples differ in the underlying database tenancy model used. The first uses a single-tenant application with an isolated single-tenant database. The second uses a multi-tenant app, with a database per tenant. The third sample uses a multi-tenant app with sharded multi-tenant databases.
Standalone application
This sample uses a single tenant application with a single tenant database. The sample can be deployed for multiple tenants. Each tenant’s app is deployed into a separate Azure resource group. This could be in the service provider’s subscription or the tenant’s subscription and managed by the provider on the tenant’s behalf. This pattern provides the greatest tenant isolation, but it is typically the most expensive as there is no opportunity to share resources across multiple tenants.
If you are interested in this SaaS pattern, check out the tutorials and code on GitHub.
Database-per-tenant
The database per tenant model is effective for service providers that are concerned with tenant isolation and want to run a centralized service that allows cost-efficient use of shared resources. A database is created for each venue, or tenant, and all the databases are centrally managed. They can be hosted in elastic pools to provide cost-efficient and easy performance management, which leverages the unpredictable usage patterns of the tenants. A catalog database holds the mapping between tenants and their databases. This mapping is managed using the shard map management features of the Elastic Database Client Library, which also provides efficient connection management to the application.
If you are interested in this SaaS pattern, check out the tutorials and code on GitHub.
Sharded multi-tenant database
Multi-tenant databases are effective for service providers looking for lower cost and simpler management and are okay with reduced tenant isolation. This model allows packing large numbers of tenants into a single database, driving the cost-per-tenant down. This model works well where only a small amount of data storage is required per tenant. Further flexibility is available in this model, allowing you to optimize for cost with multiple tenants in the same database, or optimize for isolation with a single tenant in a database. The choice can be made on a tenant-by-tenant basis, either when the tenant is provisioned or later, with no impact on the design of the application.
If you are interested in this SaaS pattern, check out the tutorials and code on GitHub.
Get started
Learn more about the SaaS app patterns described above. Get started with one of these SaaS app patterns by checking out the tutorials, where you will see instructions on deploying and managing the app. Let us know at saasfeedback@microsoft.com what you think of the samples and patterns, and what you’d like to see added next.
Source: Azure Blog Feed