SaaS-ify Legacy Applications

Cloud is a trendy word today, it is very appealing to customers because of its economic model. However, many companies have legacy applications, which still generate revenues from on-premise customers but are having increasing competitions from cloud new comers. These companies face a situation: they can’t forgo on-premises applications as existing customers are their biggest asset, rewriting legacy applications from scratch is risky because a) the current staff might not have the skills to work out cloud applications to compete with new comers b) the effort might be better invested in creating new applications with promising market forecast rather than putting the old wine in a new bottle. This article describes a way to SaaSify legacy applications with a minimum SaaS platform and minimum changes to legacy applications. These changes will benefit SaaS customers as well as on-premise customers.

A legacy application

In this article, I will assume, a legacy application is one that has existed for many years, and has average performance and scalability. It is a web application, with a typical technical stack of web server, data access layer and a relational database.

A minimum technical stack of a SaaS platform

The purpose of moving applications to SaaS is to lower the maintenance cost and improve the margin, for this purpose, some common functions are required, these functions should not be left to every individual application, instead, effort should be pooled together to deliver these functions and provide a standard interface quickly to the operation team.

It is not easy to move legacy systems into SaaS, every legacy system should be evaluated carefully, even with the above-mentioned common functions in place, if the cost to make necessary changes on the legacy application exceeds the margin saving, it is not wise to change the legacy application unless there is enough business justification to do so (for example, the market forecast for the legacy application is high).

In the following, I will describe a minimum technical stack and necessary changes an existing application should make. These changes will be beneficial for on-premise application as well as they will make the application more modular, flexible and maintainable.

Database layer

In the database level, there are 3 choices:

The ideal choice will be for all tenants sharing a schema, but that comes with big challenges:

The development work to convert the legacy application to work with a shared schema will be very big. If we are to keep the database schema largely unchanged, it will mean to change every sql the application fires, for example, to add conditions "where Table1.tenantId=XXX and Table2.tenantId=Table1.tenantId". Such changes will burden the performance of the legacy application further more. If we are to change the database schema to optimize the database access layer, it will essentially mean rewriting the application. This is not acceptable for a legacy application, which has a constraint or obligation: protecting the installed base, which means the changes should not affect the on-premise version, and having two versions will create a lot of overhead.

So in this article, I argue for an existing application, we should go for separate schemas, it has the following advantages:

1. Relatively less development works on the legacy application.
2. More flexibility in tenant-based security, backup, recovery, upgrade and scaling.
3. More stability in the sense that one tenant’s failure won’t affect others.

Architecture

(Click on the image to enlarge it)

In the above architecture diagram, I listed a minimum technical stack the SaaS platform should offer.

When a user logs in, the tenant authenticator authenticates the user and the router routes the request to an appropriate instance. Because of the assumption that a legacy application has average performance, the single application instance won’t be able to handle many tenant requests. The easiest way is for the router to designate application instances for tenants, so it will route requests from a tenant to certain application instances. In the diagram, it shows tenant A goes to application A, tenant B goes to application B etc. The benefit comes when tenant A and tenant B are in different regions and they can share the application instance in different times, or if tenant B has extremely low usage (in the diagram, shown as Tenant A and Tenant B share one application instance).

Every tenant will have a separate schema because of the challenges mentioned above. As a tenant’s data increases, it is possible to assign a dedicated database to the tenant to improve performance.

Application instances will report events into a monitor queue, events include transaction (for metering purpose), abnormal events (exceptions etc). These events will be picked up by monitor, which will analyze and feed information to the SaaS admin.

The monitor also monitors user traffic. User traffic can mean different things to different legacy application, some application may be able to support 300 active users at the same time, and some application will buckle under some heavy transactions. It should be defined by legacy applications. Monitor analyzes the information, and gives instructions to scaler to scale up or scale down applications.

Meter will be interested in user traffic as well, it uses such information (along with others) to calculate the cost and decide the fee for every tenant.

Service broker is used for integration purpose. Every application will publish its service to Service Broker. When one application needs to integrate with another, it will ask Service Broker, which picks up the application that is able to serve the request and ask the Router to route the request.

There will be a lot of information passing in the platform (application up, down, abnormal events etc), therefore a highly performant messaging mechanism will be required.

All these modules should be highly error-tolerant and available: they are the backbone of the SaaS platform: if one of them fails to work, it will bring down the whole SaaS. These modules should be clustered or backed up (in the diagram, shown as stacked rectangles).

We should not build the whole stack from scratch, we can choose and pick the ones that are in the market and have undergone market tests. We may need to customize them, though, as we need to make them fit for legacy applications.

Minimum changes required for legacy applications

Suppose the minimum SaaS platform is in place, the legacy application will need to make some changes to fit in. Most of these changes will make the legacy application more flexible, more modular, so it is a good thing even for on-premise customers.

These changes should not be taken by individual legacy applications. Just like the minimum SaaS platform, these required changes are common to all legacy applications and resources should be pooled together to work out common solutions.

Flexible configuration

A typical application (even for a non-legacy one) hard-codes configurations in some files, such as database location, ip, port etc. In a SaaS environment, resources (ip, port) are dynamic. This requires the application to have flexible configurations, for example, to link to a tenant schema based on the request routed by the Router (technically, this will mean the application should have multiple connection pools, another reason to fix the relationship between tenant and application - if application is free to serve tenants, every application will need to request connections from all tenant schemas, unacceptable for a database).

Logging and monitor

A typical application (even for a non-legacy one) logs things into files, the log files are crucial for problem troubleshooting. In a SaaS environment, since application might serve different and multiple tenants, logging to the same file is not acceptable. Administrators should be able to extract a complete record for a given tenant at a given time. In the architecture suggested in this article, application logs are directed to the monitor queue, which will be monitored and analyzed by the monitor and notified to the SaaS admin.

Caching

A typical application (even for a non-legacy one) has some caching mechanism which caches static and commonly used information in the memory. Because the SaaS application might serve different tenants, the application will need to store and fetch tenant based information from the cache. In technical terms, this could mean having one cache for one tenant either in process or stand along, or it could mean storing tenant-labeled information in the cache.

Benefits for SaaS

At the first stage, the main benefit will come from standard and intelligent management of SaaS applications with the monitoring, auto-scaling tools etc. It will also enable SaaS team to provide pay-as-you-use billing service, which is feature that is commonly required by SaaS tenants.

If legacy applications’ performance can be improved significantly, more benefits will come from sharing application instances among SaaS tenants. The above architecture is based on the assumption that legacy applications have average performance, so one or more application instance must be delegated to one tenant. If legacy applications can be made more performant, application instances can be shared more. Less application instances, less maintenance effort (and of course better user experiences).

Benefits for legacy applications

Legacy applications are called legacy, not only because they have lived for a long time, but also because they are burdened with legacy technologies. The above architecture diagram only depicts the minimum SaaS technical stack, but we already can see the opportunities to build or import cutting-edge technologies. For example, the monitoring tool can monitor exceptions in the log, user activities, stress on the system - such information will enable the administrator to smartly monitor the system, and react to system abnormalities quickly.

It will also help modularize legacy applications, as some functionality can be externalized, such as monitoring, cache and configuration.

All these changes should be taken together by all legacy applications to achieve best return of investment. These changes will also benefit on-premise customers, so it will be a win-win situation for legacy applications.

About the Author

Chen Ping lives in Shanghai, China. She graduated with a master degree in computer science in 2005, and since then she has worked in Lucent, Morgan Stanley. Right now, she is working in HP as a dev manager. Outside of job, she likes to travel and study Chinese Medicine.