Types of Multi-Tenant SaaS Architectures – One Size Does Not Fit All

Currently there are several types of successful multi-tenant SaaS applications in the market. The right architecture is driven by the type of customers you are pursuing, the volume of data per tenant, the projected volume of transactions per tenant, the types of transactions your tenants will generate (% Read vs. %Write), tenant specific security requirements (data isolation), your BI and reporting model, your tenant pricing model and your uptime SLA.

In short, the business model should drive the architecture.

So what are your architecture options? Most SaaS applications use one of four following architecture models to deliver the application. They are:

Option 1: 100% Virtualization (VMs) at all layers, multiple databases, multiple versions of the application, each tenant gets their own VM slice. Complex scripted provisioning. Manual customization for each tenant. In some ways, this is a repackaging of the ASP model with virtualization technology. Advantages: Low start up cost. Everything at the hosting layer can be outsourced. You only buy what you need upfront. Good for selling into large enterprises that want their data on separate physical hardware if necessary. Disadvantages: Slow to deploy due to customization needs. Application upgrade rollouts can be a nightmare without the right platform toolset like VMware ESX server.

Option 2: Virtualization at the application layer (hybrid). Multiple databases on in single server via federated database. Scripted provisioning. Manual customizing for each tenant. The advantages: Low to medium start up costs. Medium difficulty to design and build. You only buy what you need. Good for selling into mid to large enterprises that want their data on separate physical hardware if necessary. Easier to manage at the database layer and data storage layer when you have a larger number of tenants. Disadvantages: potentially higher startup costs at the DB layer. Can get unwieldy to manage with a large number of tenants. Not really suited for the SMB market. Slow to deploy due to customization needs.

Option 3: Single application deployed on a web farm, Single DB instance leverage or federated DB. Customization is done dynamically by the customer via the application. Advantages: Scales up. Medium to low infrastructure cost per tenant. Fast tenant deployments (Hours). Disadvantages: complex to build and medium to large upfront costs.

Option 4: True SaaS. Single database, Single instance, Single app. Customization is done dynamically by the customer via the application. Advantages: Scales up. Lowest cost per tenant. Fast tenant deployments/provisioning (minutes). Disadvantages: complex to build large upfront costs. Reference architecture: Salesforce.com

So if you are looking to be the next Salesforce.com with thousands of concurrent users, a low infrastructure cost per user is critical. Keep in mind, to drive down the cost per tenant will require a very large upfront capital investment -- if your application has a significant amount of write transactions and a 99.999 uptime SLA.

Assuming low infrastructure costs per tenant are a major driver in your business model, a single database and single schema should be the first design to evaluate. However, with a single instance/schema database you will need a database engine that can scale up and scale out. Few database engines in the market currently satisfy this criterion. Your choices are Oracle with Real Application Clusters (RAC), MYSQL with clustering or replication depending upon the volume of reads vs. writes or DB2 and Microsoft SQL Server if you want to go down the data partitioning path.

At the presentation layer, most SaaS Apps have made the choice to deliver the application via a web browser. The browser provides a set of constraints that limit your development tool choices-- unless you want to force the user to download plug-ins or browser controls. Most commonly, applications present to the browser using a combination of XHTML and JavaScript a.k.a. AJAX. The presentation layer can be served up a combination of web servers and application servers depending upon the technology stack you choose. There are viable options in the Microsoft stack (ASP.NET, C#, IIS, AJAX), Java stack (JSPs, Servlets, EJBs, AJAX) and even the Linux Apache MSQL PHP (LAMP) stack. Your choice will depend upon you development team’s skill sets and your budget for development tools and the requirements of the application.

Unless you plan on delivering all information via your fixed UI framework you will want to consider a reporting engine to allow users to customize the retrieval, presentation and formatting of tenant specific data. Most off the shelf reporting engines are not designed or licensed for SaaS deployments. The current paradigm for the market leading BI and reporting tools is the perpetual license and enterprise sale. For example, no single vendor or solution on the market today supports a true multi-tenant database architecture. The result: you will need to allocate significant resources and time to either building or integrating a reporting solution.

Another issue to consider when implementing a reporting solution, is how you deal with custom data fields. Typically, there are three approaches in the SaaS world. You have the custom schemas for each tenant, pre-allocated fields, name value pairs and storing the data in XML inside the database. Each technique presents unique challenges and limitations.

If you take the XML approach to store custom fields you will want to make sure your reporting solution supports XML data types and offers robust capabilities for parsing XML. You’ll need to consider your access patterns. Meaning do you always want to retrieve/save these fields when you retrieve the information, or just sometimes?

If you decide to go with XML you may want to consider push parsing to the app layer (cheaper to cluster) versus the db layer. You choice will depend upon how efficient your database engine at handling XML natively. Again, today no reporting vendors have great support for this type of per-tenant extensibility.

As you can see you have many options and choice to make when selecting a SaaS architecture. Ultimately, the right architecture will be determined by carefully mapping of the business requirements to the technical architecture.