One of the more unique things about SQL Anywhere OnDemand is the tenancy model we are proposing in a SaaS environment – one database per customer. I wanted to give a brief overview of it here, and 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.
SQL Anywhere OnDemand, currently available in beta, 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.
- The complexity of this implementation is expensive and error prone.
- Managed together, tenant data could potentially be exposed to other tenants in a variety of ways.
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 OnDemand comes in. SQL Anywhere OnDemand allows an ISV to scale the database management layer by the number of databases. It provides an infrastructure layer that can help 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 OnDemand 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 OnDemand is ideally suited for ISV’s looking to offer SaaS solutions to the market.