How not to deploy an application over a WAN

Some applications just aren't fit to run on a WAN. The challenge is working out which ones they are, as a reader discovered.


In a previous article we discussed some of the characteristics that determine whether an application is WAN-friendly or WAN-vicious, and gave a feedback from a reader. Today, we are going to provide some additional insight into this topic from another reader. The reader worked as sales VP for a carrier when it first introduced its frame relay service. One of the carrier's customers was a medical clinic that decided to run its medical appointment application over the carrier's frame relay network instead of over the clinic's existing regional T-1 private line network.

The issues that arose while attempting to deploy that application over the frame relay network provides a lot of insight into how not to deploy an application over a WAN.

Perhaps the most important issue is that the carrier failed to benchmark the performance of the application and the existing T-1 network. As a result, there was no agreed reference point for how well the application was or was not performing prior to cut-over to the frame relay network.

Although the medical appointment application was advertised as being client/server based, it wasn't. In particular, the application was designed in such a way that the data in each field was sent character by character over the network. Hence, this was another example of an application that runs well over a LAN but presents performance problems over a WAN.

The delay on the carrier's frame relay network, while greater than the delay on the T-1 network, was well within what could be expected for a frame relay network. However, after the application was deployed on the frame relay network, the users complained bitterly about the performance of the application. Upon further investigation, the end users stated that there were certain functions and commands that they had to stop performing due to the unacceptable performance under the old T-1 network. However, as mentioned, the carrier had failed to benchmark the performance of the application prior to cut-over, and so was unaware of the existing performance issues. As a result, the carrier did not realise that a small amount of additional delay was likely to cause further problems.

As a painful aside, the provider of the medical appointment application offered to rewrite the application to run more efficiently over the WAN. However, it wanted to charge the medical clinic $300,000 for the re-write.

So what can we learn from the above experience? One thing we can learn is the importance of benchmarking network and application performance. The second thing is that it is also important to model the performance of an application prior to either deploying that application, or changing the underlying IT infrastructure.

Find your next job with computerworld UK jobs