Unlikely as it may seem, not every network slowness issue is solved with a WAN optimization or application delivery...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
controller. Learn the top five WAN application delivery optimization deployment mistakes made across enterprise WANs, in this article below.
The issue: WAN application delivery optimization is not a hammer; performance problems are not nails.
Just as it is important to have a must-do list in mind when approaching deployment of a WAN application delivery optimization (ADO) solution to fix a performance problem, it is also important to have a clear set of actions in mind that IT will avoid doing. After all, ADO technologies are many, varied and sometimes irrelevant. It is important not to assume that every performance problem will be fixed by a WAN optimizer or application delivery controller (ADC). It's important not to think each optimizer or ADC can do all the same things any other ADC or optimizer can do. It’s also important to apply good management philosophy to ADO deployments. Based on conversations we've had at Nemertes Research with scores of IT executives over the last few years, here are the top mistakes to avoid during WAN application delivery deployments.
Top five mistakes of WAN application delivery optimization deployments
1. Surprise people.
Because of how often WAN optimization succeeds—over 70% of deployments are judged very or extremely successful in Nemertes’ research—some IT folks have a very human urge to slip it into place on troublesome WAN links to magically solve everyone’s problems. As with any other kind of change to production services, though, making uncommunicated and potentially disruptive changes to connectivity is a job-ending event—sometimes even if it works.
2. Assume you have to buy something.
These days where MPLS is a primary WAN technology, it is easier than ever to get differentiated delivery services on the WAN. Most MPLS networks allow the client to define four or more classes of traffic. IT can define some traffic classes so they receive special treatment such as protected bandwidth or prioritized delivery. If this resolves performance problems, IT does not need to buy a WAN optimizer or other ADO appliance. This can be especially effective if the applications having trouble are real-time communications tools, such as VoIP or other unified communications applications.
3. Buy before you try.
It is dangerous to your budget and possibly to application performance to assume that a WAN application delivery solution will fix your problems because it worked for someone else—or because another appliance you have from the same vendor works. It is essential that IT test solutions in situ.
4. Buy the first thing you try.
Just as it is wrong to buy something because a vendor recommends it to you, it's as equally wrong—and I know how odd this sounds—to buy something just because it works. Since other solutions may cost less, do more, or work as well or better, IT must try more than one solution.
It is painful in the extreme to fix someone’s performance problems and then have to tell him or her that the fix is going away so that you can try a different fix. Unfortunately, this can be unavoidable in an ADO trial. Some IT shops can manage to test several solutions at once, using different WAN links as the guinea pigs, but most are not in a position to do so, at least not for in-house, appliance-based solutions. Virtual appliances and cloud-based solutions should make this a whole lot easier, as they allow IT to turn up services without having to install new hardware in remote locations or pull it back out again later.
5. Fail to document your success.
More than one IT exec has said to me, “WAN application delivery optimization made us heroes.” It is rare indeed for IT to be able to effect so dramatic a change with so little disruption to the end user. The best case scenario is that users at a branch leave one day with a problem and come back the next day to find it resolved.
Unfortunately, it is also rare for IT to properly trumpet such successes. Bragging is to be avoided—hubris is never pretty—but documenting the before and after pictures is critical to building IT’s credibility as a problem-solving organization. Moreover, the success has to be documented in ways that make sense to upper management aside from the CIO. IT needs to put its success in terms of staff work hours formerly lost in waiting, and if possible, translate this to dollars not wasted. This could also be documented as additional work completed in a typical work day, where such data is available, and tied to application performance over the WAN. Doing either may mean talking to the business units more, which is never a bad idea. IT can also put savings in terms of costs avoided—such as the costs of increasing WAN bandwidth, server counts or the number of data centers that have to offer a service.
If IT can avoid these pitfalls of a WAN application delivery optimization deployment, it will be well on its way to solving important performance problems in ways that will not only benefit staff and help the company get its work done more effectively, but will also, in turn, benefit IT by increasing its perceived value.