The Case for Distributing Applications

This column is in response to a question from an NDCF reader concerning the challenges involved in linking a new or expanding data center to other sites or Internet portals. The reader also wanted to know how this affects data center costs.

In my view, these challenges can often be an opportunity in disguise an opportunity to distribute applications to other sites with the goal of not only improving service levels but also limiting communication costs.

Before I make my case for saying this, let's go back to basics and review what I mean by "service level," which can be divided into two major components. First is the reliability of the applications, and second is the response time provided to end-users of various applications required during normal operations. The way I like to think about this for an individual application is:

Application availability/reliability has two components: how service is provided during normal operations, and how service is provided during and after a failure. Of course, there are many kinds of failure, and this is what leads us to remove dependencies on single points in the system – each of which could fail and result in a system-wide loss of service. One of these points of failure is the communications infrastructure to allow users or other applications to connect to the applications needed by the organization.If a data center is to survive a catastrophic failure, the communications infrastructure between at least the primary site and backup sites must be sufficient to limit data loss and reduce recovery time. Providing adequate responsiveness for applications is also often dependent on communications infrastructure and drives requirements for high-bandwidth, low latency communication channels.

When considering communication requirements and the resulting costs for a data center, the designer must also take into account specific applications hosted at the site and their architecture. A centralized application that operates from servers at the data center, and requires a browser or terminal services client at some remote location, will drive requirements. This will generally result in the highest possible communication costs, because both the user interface and all interaction with the application must be delivered over the network. Understanding the complexity of the user interface and the number of concurrent users can help fine tune these requirements. A completely distributed application can have a much different communication footprint...

Allowing your business applications to be deployed in a distributed manner that directly supports disconnected use and remote execution will improve the end-user’s experience. Applications need fewer data center and communication resources, while at the same time providing a service level that is generally better than the centralized approach, and at a lower cost. Let’s take a concrete example: a CRM application used by 1,000 concurrent users who support 100,000 customers, assuming 900 of those users are spread over three call centers and the remaining 100 uses are at the central office.

A centralized solution would require a data center capable of supporting 1,000 concurrent users, and a significant communication infrastructure for corporate, call center, and backup data center. A continuous failover recovery process would be implemented to provide adequate reliability. A communication circuit failure would likely cause one third of the users to lose access to the application unless those were doubled up as well.

A distributed remote office approach, on the other hand, could use a smaller corporate data center, regional servers at each call center, and maintain a synchronized dataset at all sites, eliminating the need for a backup data center (or at least enabling a smaller disaster recovery plan).Communication requirements would be limited to the data synchronization channel, since the application would be delivered locally at each call center, directly to 300 end users – moving most of the requirements for low-latency communications back into each regional call center’s LAN.

A communication channel failure between the data center and regional call center would not stop use of the application; rather, it would delay replication of database changes. Applications therefore would remain 100 percent available at each regional call center. With this architecture, the failure of any server would result in a loss of service to no more than 300 users, allowing the remaining 700 users to support the business.

A completely distributed approach, where each call center employee has an instance of the application on his or her local PC, along with enough data to support use of the application, can further reduce the need for regional servers (they would only need to support data synchronization and application delivery). This would not dramatically affect communication costs, but it does enable mobilized use of the system, and that may have a dramatic impact on cost savings, allowing employees to work effectively outside a regional office. For some applications, this can result in superior customer service – bringing the application in front of the customer.

D. Britton Johnston, Chief Technology Officer, PeerDirect Inc.