This set of articles was first published on my Sybase blog in 2009. Since that time, this 5 part series has been one of the most requested set of articles. As part of Sybase's integration with SAP and the shutdown of the Sybase blog server, I am republishing them on the SAP SCN, and taking the opportunity to update them.
When considering multi-tenant architectures with SQL Anywhere, there are several different approaches that can be used to serve up data for several customers or "tenants".
The need for an ability to serve data for many customers usually shows up in hosted environments. This approach has been used for years, but has recently gained attention under the names “Software As A Service” or “Cloud Computing“. An interesting aside I find humorous is that several SQL Anywhere partners have been hosting systems for their customers for years, but have just recently bowed to the marketing pressure and started to call their hosted service a “Cloud”.
The primary end-user customer perception of a hosted or cloud environment is that their data is stored somewhere else. They don’t exactly know where, or how, but they trust their application service provider to keep it safe and secure, and they get access to their data over the internet.
Because the hosted system will be holding data for many customers, the primary difference between the different architectural approaches will be how isolated one customer’s data is from another customer’s data. These approaches lie along what I will call the “Spectrum of Isolation.”
The most interesting discussion for a database developer around cloud / multi-tenant systems is to understand how the data is stored. Many questions arise, including:
- What is the database architecture?
- How many servers are used?
- How does the system support a large number of customers?
- Can the system handle both very large customers, as well as many small customers?
- Can that database and application be customized for some customers?
I plan to address many of these questions in a series of posts related to this topic. In this first post, let’s look at the factors that must be considered during an evaluation of potential architectures. These factors are really trade-offs. There is no “one-size-fits-all” approach to implementing a multi-tenant database system.
When evaluating these tradeoffs, you must understand your own application’s requirements and capabilities, as well as your customer’s requirements. If you don’t understand the true nature of these aspects, then you have little hope of making the right decisions.
Everyone wants a hosted system that requires no development effort, runs on the cheapest hardware, has blistering performance on queries, has the highest imaginable security, and handles millions of customers, each of which has their own customizations. Since all of these can’t be true at once, a balance must be reached between these various tradeoffs:
- Your development time
- Hardware cost
- Application and database performance
- Security
- Customization requirements
- The number of tenants
As we look at the various architectural approaches to implementing a multi-tenant system, I will highlight the implications on each of these factors. It is up to you to choose the correct balance that works for your application and customers.
In part 2, I’ll examine the “Separate server” and “Shared server, separate database server process” architectures.
(1, 2, 3, 4, 5)
