SaaS model is taking cloud application business by the storm and, as of 2023, the SaaS industry is worth approximately $195 billions and growing (Gartner). Companies are less and less developing in-house solutions and are instead more relying on 3rd party SaaS solutions for larger chunks of their application portfolios, from HR to Finance to Production and procurement. It’s expected that by 2025, 85% of business apps will be SaaS-based (BetterCloud), and SaaS business it is expected to grow dramatically over the next years driven by both large established players and new growing startups.
The multi-tenancy challenge
Multi-tenant design is a critical aspect for every SaaS company to increase resource utilization, cost efficiency and achieve desired margins as, in most cases, databases are the biggest item in their monthly bill. No matter if big or small, finding the right multi-tenancy model at the database layer is a complex subject, and it requires the right trade-off between performance, costs, tenant isolation, security and other critical areas.
Today, many successful SaaS application providers of all sizes are designing their solutions around the “database(s) per tenant” model, which is providing great benefits in terms of tenant isolation for management operations (backup/restore, monitoring, etc.), security requirements and scaling, but at the cost of building their own database management layer to deal with the end-to-end lifecycle of their fleets, from few thousands to even millions of tenant databases.
Entering Azure Database Fleet Manager
Azure Database Fleet Manager is a built-in, first-class offering in Azure Database Platform based on the operational experience of the largest 1st party SaaS offerings from Microsoft (like SharePoint Online, Dynamics 365 and Power Platform) that removes the complexity of managing the end-to-end lifecycle of their operational databases.
Primary goal of Azure Database Fleet Manager is to dramatically simplify provisioning and management of database fleets of all sizes. To achieve this goal, we are introducing a number of abstractions that hide underlying platform entities like logical servers and elastic pools that, while providing a great experience for small sets of databases, are introducing several constraints and limits (e.g. max number of databases per pool or per logical server) and creating unnecessary complexities for developers in areas like capacity planning, resource allocation and re-balancing across large fleets (Am I filling up my pool and need a new one? Which size should I pick up?).
These abstractions instead are exposing a policy-based approach that SaaS application owners and administrators can leverage to directly control all aspects of their database fleets, like price/performance ratios, security, and business continuity configurations and such, or let the platform to apply smart defaults that take away most of the underlying complexities.
SaaS architects and developers can then focus on their tenant provisioning logic and lifecycle management and leverage a simple, infinitely scalable API to create databases, monitor them and execute database management tasks at scale.
Let’s explore these abstractions and their behaviours:
SaaS administrators define a fleet (or use a default one) as the higher-level entity to create and manage unbounded sets of databases that can exist in one or more regions, and at least one (the default) or more fleetspace definitions that can be used to logically group databases into manageable units.
A database within a fleet is always associated to a fleetspace (default or explicitly created), a regional, unbounded database grouping concepts that act as a “blast radius” boundary for management operations like schema changes or index maintenance. Fleet administrators can create a fleetspace in each geography they want presence in and may decide to create more if they want to group databases and have more granular control over management operations that can potentially impact thousands or more databases.
Note that there are no limits to the number of databases associated to a fleetspace, they can scale to hundreds of thousands or even millions.
Fleet owners can create policy-based database tier definitions. These are declarative artifacts containing multiple sections with specific attributes like database engine of choice, price/performance objectives, security settings, high availability configurations and such. When customers create databases with a given tier definition, the platform will use policy definitions to manage all aspects of database lifecycle.
To simplify the experience for fleet administrators, a rich set of pre-defined policies will help them to define a tailored database experience at a given COGS.
Azure Database Fleet Manager drastically reduces administrative efforts for SaaS solution providers of all sizes and removes any boundary regarding limits and the complexities of underlying resources like logical servers and elastic pools. It also enables policy-based resource management and intelligence rebalancing of databases across pools within a given tier, to decrease overall resource utilization (and costs) while maintaining a good performance experience for database users.
Here is an overview of the end-to-end experience creating and using Azure Database Fleet Manager:
Note: information and prices shown in the video are there for pure demonstration purposes and are not final.
Private Preview for Azure Database Fleet Manager will start in a few weeks, and you can submit your candidature using this form. This is a gated program where participants will be selected based on their specific use cases and scenarios, so please make sure to provide full description of your solution and requirements in the form. An open Public Preview program will be announced over the next months.
We're super-excited to start engaging with you on this journey!