Jim was recently hired to consult for the IT organization of a Fortune 500 company. The problem that the company is facing is that it recently deployed a new application and is hosting it in the United States. When some users in the Pacific Rim try to access the application, they experience unacceptable delay. The IT organization is looking to Jim to help it decide if it should either change its WAN design to reduce the overall latency or else build a new data center so that the application can be hosted in both the United States and the Pac Rim.
The problem facing this organization is typical of the type of problem facing most IT organizations. As the senior director of infrastructure services at a Fortune 100 company recently told Jim, "I get beaten up on a weekly basis for application performance." The director's comments reflect the fact that over the last several years, responsibility for application performance has fallen either broadly to the company's infrastructure organization, or more narrowly to the company's network organization.
One of the primary reasons that application performance is such as issue is that in many cases applications are written in such a way that they perform badly over the WAN. For example, the era of mainframe computing was characterized by the deployment of monolithic applications. The phrase monolithic application refers to an application in which all the relevant functionality (i.e., the user interface, the application logic and the database) resides on a single computer. However, while application architectures have evolved from being monolithic to being highly distributed, most software is written as if all the software were running in a single data center. Regrettably, for reasons that we have discussed before, applications that run well over a LAN do not always run well over a WAN.
In addition, in the typical application development environment the focus is on delivering the promised software functionality on time, on budget and with relatively few bugs. In most cases, there is little if any focus during the design and development of an application on how well that application will run over a WAN. One IT architect we spoke with said: "The worst architectures come from some of the software vendors and that there is no rhyme or reason to what some of them do."
One simple example of a WAN-vicious application that we were recently made aware of involved an application that would send a 2MB file to remote users. The software on the client would open that file and extract a 10-digit code.
Next time, we'll continue the discussion of the role that the WAN plays in supporting application performance. We'll also discuss the role that the CIO plays in ensuring appropriate application performance. In the meantime, we would like to hear from you. Kindly send us examples of WAN-vicious applications that you have come across.