Building a SaaS Style Application

SaaS Patterns – A Problem-Solution Approach

Abstract

Software as a Service (SaaS) adoption is on the rise in the enterprise world, driven largely by its

promise to deliver „capital expenditure avoidance‟, „quicker time-to-market‟ and „reduced risk‟. To

capitalize on the SaaS wave, Independent Software Vendors (ISVs), Service Providers (SPs) and Service

Centered Businesses (SCBs) are quickly moving to deliver service from the Enterprise Cloud[1]. Usually,

such vendors are focused on product/service features and not on serviceability. This makes the

challenges in transition to a „SaaS Provider‟ easier said than done. This article discusses 7 Key

Challenges in architecting software to be delivered as a service.

Introduction

If you are in the software industry, chances are that you have heard the term SaaS by now. Companies

like Salesforce.com have been extremely successful in bringing this concept to reality and opening up

untapped markets for business.

Chances are very unlikely that you will be constructing a full blown SaaS application to be marketed

worldwide; but you can take key concepts from „SaaS Construction‟ and build your next in-house

application in SaaS style, still reaping most of the SaaS architectural benefits. You will be amazed that

any Google search on SaaS throws up hundreds of results on the business side of SaaS and very little on

the technical side. While one can get low level technical details on the data modeling side of SaaS from

the Microsoft website, as a technologist you will need more patterns to jumpstart your SaaS journey.

The following article is a compilation of my thoughts to fill the void I found.

‘SaaS Patterns – A Problem-Solution Approach’

1. Problem (Database)

Business problem: How can business lower the „cost of service‟ without compromising on QoS?

Technical cause: Can a single database instance be used to capture many client‟s (tenant) data,

thereby promoting economies of scale? How will architectural attributes like Performance,

Extensibility, Security, Customization, etc… handled in multi tenancy?

Solution

A simple, yet elegant solution, to this problem is to insert Client Id (Tenant Id) as an additional column

in each table storing multi-tenant data. Now, how do you make this solution cope with extensibility,

performance and security requirements?

Extensibility: For extensibility, the data in the database can be held in an XML CLOB without defining a

hard schema. As extensible as XML is, it brings its own downsides in CRUD operations – XML queries are

relatively slow and cumbersome. If XML is not a preferred option, you can design tables with generic

columns or extension tables (tree structure) for handling extensibility.

Performance: Generic design and performance generally don‟t go very well together. In most

instances, to scale one you have to sacrifice the other. One workaround to this problem is to

accommodate key search fields within the data model. This will assist in faster SQL-based querying.

Security will be handled in the next section.

Fig 1. Tenants having a separate database each versus a shared multi-tenant database in SaaS

2. Problem (Database - Security)

Business problem: How will the customer‟s „IP Protection‟ & „Data Security‟ be guaranteed?

Technical cause: How will data security be enforced at the Architecture level? Every resource

should be locked down with the tenant details, so that even if hacked by application developers one

tenant‟s data should not be made available to others.

Solution

You cannot protect something if you do not know where it is. So, the first step in ensuring client data

security is to add a Tenant ID column to all the tables in the database. However, this alone is not going

to provide the required level of security - we cannot rely on developers who write the queries to be

mindful of security concerns.

The next level of securing client data involves preventing unauthorized access at the database level.

This requires some kind of support at the database level.

To achieve this in a SQL Server environment:

1. Restrict direct access to tables for tenants; administrators can be given direct access

2. Create a unique database ID for each tenant

3. Map tenant ID to database ID in a particular table

4. Create table valued functions which take the tenant ID and return the data as a table

5. Create a view that calls the table valued function

6. Give access to the view for tenants

If you are using an Oracle database, then Oracle‟s Virtual Private Database (VPD) / Oracle Label

Security (OLS) can be used to come up with a solution. Similar implementations are feasible in MySQL.

The advantages of this approach are that security is handled at the architecture level and is fool proof

from hackers. Additionally, there is no overhead for developers and it provides for transparent handling

of tenant details.

Fig 2. Security relying on Tenant‟s good intent versus security enforced at database level in SaaS

3. Problem (Meta Data Services)

Business problem: How can SaaS service providers be agile to their customer‟s needs?

Technical cause: How can configuration data kept minimum thereby enabling simplicity? Every

component in the system can have its own configuration structure ending up in a separate file or table.

The meta-data will increase exponentially as the number of components & number of tenants rise.

Solution

Most components have their default meta-data values and tenants do not always override the default

setting. In many situations, a hierarchy of default values exists. For example, a company can set some

default settings, and at the next level a department can have its own settings, etc.

Now, we end up with two main themes

1. Meta-data hierarchy (e.g. user-department-branch-country-company)

2. Overriding Priority (In a meta-data hierarchy, some features have top-down priorities while

others have bottom-up priorities)

Meta-data services should handle highly configured component meta-data and less configured meta

data in slightly different ways.

The following solution is applicable for meta-data with low levels of tenant overriding. (While the

solution discusses configuration files only, the same applies to database configurations as well.)

1. The default component meta-data should be stored in the application level folder structure.

2. A similar folder structure should be maintained for every client who overrides the default data

- note that only the files that are overridden should be saved for that tenant.

3. At the time of client login or application startup, the meta-data service should load all the

tenant hierarchy and tenant specific configuration and super impose them in the right order to

obtain the tenant-specific data.

Meta-data services can also exhibit an event notification mechanism using the “publish-subscribe

pattern”, where any changes to the meta-data can be communicated to the layers above.

Note: Depending on the complexity of the solution the meta data services component can be build

from ground up or a FOSS framework like Obix, JFig, etc… which can be used/extended.

Fig 3. Hard coded logic in component for handling multi-level configurations versus a generic &

structured approach to multi-level user/tenant level meta-data handling in SaaS

4. Problem (Tenant aware Controller)

Business Problem: What technical assets will speed up a SaaS service provider‟s time to market?

Technical cause: How can the application controller navigate the tenant to the next tenant

specific step? Navigation can range from a high level of navigating from the business logic to the view

or business logic to data access or any macro level step.

Solution

Navigating or Tenant Flow Orchestration is an extension of the Controller component from the MVC

design pattern. The Controller has the base flow or orchestration configured.

Within a SaaS framework, we need to slightly change the way the Controller handles event

orchestration. When the Controller receives a service request, instead of directly handing over to the

next step, the Controller should call the meta-data services to get the reference for the next step.

When there is customization or overriding performed at the tenant level, the meta-data services will

return this information which will be used by the Controller for orchestration.

For example, a business service A may have AI.jsp as the input screen and AO.jsp as the output screen.

If this action requires customization for 5 clients with different input & output pages, one way to

handle this is to hard code the input & output jsp in the controller XML under 5 customized actions. A

much better way of doing this is to have one service A defined with logical input & output pages and

let the controller get the absolute pages from the meta-data services.

Fig 4. Controller in MVC referring to absolute resources versus a Logical controller doing absolute

resource mapping with the help of a meta-data services layer in SaaS

5. Problem (Infrastructure Services / Setup)

Business problem: How to guarantee „High Scalability & High Availability‟ of my SaaS service?

Technical cause: Even though SaaS promotes economies of scale through multi tenancy at times

we could be forced to take tenant specific actions to achieve scalability and availability.

Solution

Having a group of application clusters and letting all tenant users hit servers through a load balancer is

a simple solution which will work for most SaaS implementations. However, the service provider might

also have a tiered Tenant model and/or different SLAs for different tenants. In the latter case, you will

encounter the following specific requirements from the infrastructure deployment:

1. Performance & Scalability throttling based on Tenant Priority

2. Reduced static deployment downtime based on Tenant Priority

The solution is to form tenant clusters, so that there is segregation of tenants by priority and SLA

requirements. To achieve this routing you need a “Tenant Aware Load Balancer” to route requests

appropriately. The login authentication could be done on a common server but further requests should

be routed to the tenant farm at the load balancer level rather than at the application level.

While deploying this solution, you should also take care to achieve the following:

1. Prevent tenants from requesting resources when a tenant specific deployment is underway.

2. Retain tenants with high priority/ low latency SLAs in dedicated clusters so that they do not

face downtime while services for other clients are being deployed.

3. Segregate clients with lower priorities/ lower level SLAs into shared clusters where you can

utilize the scheduled downtime to run updates/ service deployments without facing SLA

penalties or customer dissatisfaction

4. Every tenant should have at least one backup server in the cluster to ensure availability.

Fig 5. A Load Balancer routing requests to a common server cluster versus an intelligent load balancer

routing to common, tenant specific clusters & Security service in SaaS

6. Problem (Performance Throttling)

Business problem: How to design a „SaaS service‟ to provide client priority based servicing?

Technical cause: Caching at multiple levels is one of the best ways to improve application

performance, how to take advantage of application level caching with tenant priority? This problem not

only applies to caching but also to places where tenant priority based processing needs to be done.

Solution

Caching solutions range from a single JVM cache to a distributed cache to caches at other layers like

database etc. Best practices like setting the maximum cache size, expiry policy, etc… improve cache

and overall system performance.

In a SaaS application, it is always better to have flexibility to serve important tenants quickly. This

means that a caching solution or a service queue pattern has to include tenant priority in its processing

logic. For example, a cache solution should indicate the maximum cache size permitted for each

tenant and should be able to keep track of it, instead of just tracking the overall cache size at the

application level alone. It should have the ability to remove objects based on tenant priority

algorithms. A similar solution can be extended to service queues or other places where tenant priority

based processing is required.

Fig 6. Multi-level caching at the application level versus multi-level caching with tenant awareness to

control the tenant cache size and expiry logic in SaaS

7. Problem (Error Handling)

Business Problem: How can client delight be improved by addressing client specific issues faster?

Technical cause: Error handling is very important to debug production problems; needless to

highlight its importance in a multitenant environment. Logging style of Distributed components &

different layers could differ. „Log time‟ is crucial in co-relating the logs to understand the big picture;

multiple time reference (machines/zones) adds another layer of complexity to this problem.

Solution

There is no single silver bullet that gives a readymade solution to all of the above stated challenges.

But careful selection of a few can address most problems:

1. Considering log as a “Separation of Concern” and using AOP for logging

2. Consolidating error handling in a single area using the “Fault Barrier” pattern

3. Using Asynchronous log mechanisms

4. Logging to a centralized place using a queuing mechanism

Distributed high performance low latency applications can log using a queuing mechanism. Depending

on the criticality of the logs, a memory buffering technique can be used to minimize IO operations, if

the downside of losing a few messages (rarely) is acceptable.

Fig 7. Application level logging to a common file versus tenant specific synchronous / asynchronous

logging using the Fault Barrier logging pattern in SaaS

Conclusion

To the technical community, SaaS is an IT service deployment methodology that is becoming

increasingly popular and which they need to understand and use to stay current. To ISVs, BSPs and

EHSPs, SaaS has the potential to open up an untapped market with significant revenue possibilities.

The SaaS business model, with its inherent cost advantages, may only be a few years old, but the core

concept of application resource sharing at various architectural levels has been with us for a long time.

It is just that recent technological advances have opened up new and economically viable ways of

addressing the problem of sharing resources.

Having said that, enterprises exploring the SaaS platform as a new/ alternative business channel should

also realize that the technical implementation framework is as important as the business model

supporting the venture. Ignoring the technical aspects of SaaS implementation is a sure way to facing

downstream business disruption issues.

This article is not intended to cover everything under SaaS Patterns, but intends to be one of the first

compilations of SaaS design patterns which, hopefully, will get critics, enthusiasts & supporters to

begin contributing to this discussion and help grow the knowledge base. Few other notable SaaS areas

which need problem-solution patterns are Identity Management, Security, Integration, Monetization,

Workflow and User Access Management.

References

[1] “The State of Enterprise Software: 2009” Source: Forrester

http://www.microsoft.com/serviceproviders/saas/default.mspx

http://www.ddj.com/database/215900773;jsessionid=ZIPBUCLLD1JGSQSNDLRSKH0CJUNN2JVN?pgno=1

http://www.oracle.com/technology/pub/articles/dev2arch/2006/11/effective-exceptions.html

http://www.sqlmaestro.com/resources/all/row_level_security_mysql/