Converting a standalone Server Application to a Web-Based service

Recently a client hired us to take over converting their (very successful) standalone server application into a web-based service.

The client provides a software solution that allows users to monitor competitive search engine data and adjust their pay per click campaigns accordingly.

Their product launch was so successful, it generated 7 digits in revenues and more than 1,000 customers within 24 hours from the launch.

This meant 1,000 customers downloaded the standalone server application, created a new web hosting account and began their journey into installing and customizing the server application before it can be used for the first time.

Note: To learn more about what a standalone server application is all about, you can read my earlier post about architecture of developing a software solution.

Problems started showing up very quickly -

The server application script was very resource intensive, not designed to run in a shared hosting environment where several clients are running the script on the same machine.

Unknown to our client at the time of launch, the recommended shared hosting company had CPU restrictions in place whereby they would automatically terminate a server side script if it was running for more than 60 seconds.

Some clients couldn't even figure out how to get the server application properly installed and running.

Software Projects was hired to convert the server side application into a web-based service.

Here's the difference in user-experience between a standalone server script and a web-based service:



You can clearly see how a web-based service eliminates a lot of the headaches users had to deal with, which means lower customer support costs for our client, improved end-user experience (which leads to happier users) and a centralized product base which makes version and patch updates a breeze.

On the technical architecture level, we are in the process of rewriting the product so that it can function in clusters of Application (Engine), Database cluster and User interface layer.

While a web-based service introduces lots of benefits, it switches all the load from remote client machines to our client's servers. It is very important to design a solution that gracefully handles continual increase in load with no performance degradation.

The keys to making this happen are -
#1. Switch as much processing as possible to offline / background mode. This means - user requests should always be queued up, performed in the background by a deamon program and never performed on-demand.

#2. User interface layer should be as light as possible, making minimal UPDATE and INSERT queries to the database.

#3. Use server-side caching plug-ins such as: Memcached and eAccelarator.

#4. Design the system with scalability in mind, making it possible to scale to O(100N) by adding 100 servers. This module of parallel processing has been commercialized by Amazon and used by Google from their early days.

--

Here's a diagram that outlines the old standalone server application architecture vs. the new web-based service architecture we designed:



As you can see while the old Server Side Application architecture is a lot simpler, it implies installing the web server, database server and engine all on the same machine with little to no planning for growth.

Our new architecture was broken into three clusters -
1. Web server cluster serving the user interface to all end users
2. Database cluster, holding all user databases
3. Engine cluster, holding slave machines that perform the required crawling actions.

The system was designed to easily scale, allowing adding multiple servers under each cluster as demand increases.