Architecting the application-enabled WAN

Most companies say they’re running between 50 and 300 applications over the WAN, and many have more than 1,200. That’s scary enough, but the real issue isn’t application quantity, it’s quality. There are five basic application types, based on their bandwidth consumption and tolerance for network latency.

Last week I talked about the enormous increase in bandwidth requirements underway at most enterprise organizations. A major cause is the dramatic increase in applications.

Most companies say they’re running between 50 and 300 applications over the WAN, and many have more than 1,200. That’s scary enough, but the real issue isn’t application quantity, it’s quality. There are five basic application types, based on their bandwidth consumption and tolerance for network latency:

Network-optimized transactional apps (such as Web and Citrix). These are moderately sensitive to latency, consume a moderate amount of bandwidth, and run well over your typical WAN.

Real-time, low-bandwidth apps (such as voice and some transactional apps). These consume a moderate amount of bandwidth, but are very latency-sensitive, typically requiring a network with less than 150 millisec. Running these apps requires a quality of service (QoS)-enabled WAN.

Bulk file transfers. These are high-bandwidth, latency insensitive. Best-effort delivery is fine.

Chatty transactional applications are near real-time, higher bandwidth applications (such as early versions of PeopleSoft). These are highly latency-sensitive and consume a fair amount of bandwidth. In many cases, it’s virtually impossible to architect a WAN to support them well.

Finally, there’s interactive video, which is in a category by itself in terms of latency and bandwidth requirements. Most companies today support video on a dedicated separate network (usually ISDN) – if they do so at all – but an ongoing trend is to converge video onto the WAN, typically via QoS-enabled architectures such as Multi-protocol Label Switching.

Chances are that 80% or more of your apps will fall into these basic categories. But how do you architect a WAN that’s optimal for five different application types without building five separate WANs?

Step 1 is to understand and classify your application mix, both present and future. If chatty transactional apps represent just 5% of your traffic, but will go to 15% next year, that requires a different approach than if it’s 5% going to 2%. So start by benchmarking your application types. Then estimate their rate of change and validate the estimates with lines-of-business and application developers.

Next, estimate the individual and cumulative bandwidth and latency requirements for your mix of applications. This can be a challenge if you’re dealing with apps with a usage pattern that is unfamiliar (IP telephony, for example). This is where effective capacity planning exercises become key.

Finally, you’re ready to do some real design work.

If you’re pushing the limits of your existing WAN technology, you have a handful of choices. You can re-architect the app to reduce its “WAN impact” (using Citrix to gain access to a chatty transactional application is a common approach). You can add bandwidth-optimization products and services such as those discussed last week. Or you can enhance your WAN to meet the increased latency and bandwidth requirements.

Which is the right path for you? Ah, that’s the art of engineering design.