Republished with edits from my blog at http://iablog.sybase.com/hinsperg
One of the more unique things about SQL Anywhere, on-demand edition; is the degree of support for the "one database per customer" tenancy model in a SaaS environment. I wanted to explain why we think it is the way to go for an ISV looking to offer a SaaS application to the market, compared with the more traditional approach that is currently available for databases providing SaaS applications to multiple customers/tenants.
SAP Sybase SQL Anywhere, on-demand edition (thats quite a mouthful isn't it...) takes a fundamentally different approach to database management for SaaS applications, based on the following key assumptions about ISV customers:
- Customers running an ISV application usually have no relationship with each other
- Customers running an ISV application usually do not want to share their data with other customers of that ISV
- Different customers have different usage patterns, performance and service-level requirements
Most current database management offerings that support SaaS deployments, use a single database/server, and use replication, sharding and other methods to scale that database to match customer demands. However, this method is inherently flawed as a solution for ISVs looking to offer a SaaS application for several reasons:
- A single database server model prevents an ISV from capitalizing on the key customer assumptions made above. For example, under the single database/server model, all tenants are impacted by any change made to your environment to address any change in requirements from a single tenant.
- Managed together, tenant data could more easily be accidentally exposed to other tenants through things like security errors and as a consequence of software bugs.
- The complexity of this implementation is expensive (eg. sharding and partitioning to manage database size and scale) and this compexity also makes it error prone, which is a big problem because an error usually affects all tenants.
Worse yet is using a data-as-a-service provider - in addition the above problems, in this model ISVs have little or no control over the customer experience with their application, which makes it difficult (and sometimes impossible) to address entire classes customer problems and concerns (eg. performance problems).
In the end, using a single, monolithic database/server to manage all tenant database(s) in a SaaS environment does not make sense.
Given the above ISV customer assumptions, it does makes sense to have a single database for each of your customers. This allows you the maximum amount of flexibility in terms of
- Keeping tenant data separate
- Providing different levels of service (related to performance, availability, extra functionality etc...)
- Dealing with the demands of those customers with larger databases without impacting other tenants.
- Limiting the impact of infrastructure changes to a single tenant, or at most a small number of tenants
From a management perspective, having a single database for each customer means dealing with hundreds, or even thousands of individual tenant databases. Maintaining availability, doing backups, validating, etc... is a huge job. This is where SQL Anywhere on-demand comes in. SQL Anywhere on-demand allows an ISV to scale the database management layer by the number of databases. It provides an infrastructure that helps to manage thousands of individual tenant databases. This means that each tenant can have their own database, which provides many advantages, and allows the ISV to easily manage the administration of those databases.
By using the existing strengths of SQL Anywhere, the on-demand console allows an ISV to manage each customer in an individual tenant database. Tenant databases can be managed individually or in groups, allowing you to do things like
- Move a specific tenant database from a loaded server to one with less activity,
- Send out an upgrade script to an entire group of tenants.
- Backup and restore an individual tenant database
- Bring new resources (hosts, database servers) online (and take them offline) as customer usage patterns and requirements change.
- Restrict where a tenant database can be physically stored
The tenancy model of
SQL Anywhere on-demand is ideally suited for ISV's looking to offer SaaS solutions to the market.
