If everyone is thinking the same, someone isn't thinking

Lori MacVittie

Subscribe to Lori MacVittie: eMailAlertsEmail Alerts
Get Lori MacVittie via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: Cloud Computing, Virtualization Magazine, SOA & WOA Magazine, F5 Networks

Blog Feed Post

The Epic Failure of Standalone WAN Optimization

WAN optimization is not and cannot be separated from application delivery

Yes, yes I did say that. There's a reason for that, and after more than a decade of watching the markets that tangentially revolve around making applications faster I'm here to tell you it's a failure of monumental proportions.

The very term WAN Optimization has always stuck in my craw (whatever and wherever that may be). That's because optimizing the WAN implies that you're making the WAN faster. The problem is that a WAN is either a dedicated link between two locations (old skool) or a connection to a remote site across the Internet (new skool). In the case of the former there really isn't a whole lot you can do to that network to make it faster. In the case of the latter there really isn't anything you can do to influence the networking components out there, on the Internet (or "in the cloud" as some are wont to call it these days) to make it faster.

app delivery vennIn the data center, optimizing the network has real meaning. It's about modifying routing and switching, moving segments and changing VLANs. It's about fatter connections and changing the way in which network traffic flows through the pipes.

But when it comes to the WAN, you've got very little to tweak.

This is the reason that when folks said WAN Optimization what they really meant was "we squish data down so there's fewer packets and thus, it traverses the network faster.”



What IT and business stakeholders really want - what they care about and what they're basing key performance indicators on, however - is faster applications. And if you focus on optimizing the network, well, that's not really the right approach. The right approach is to focus on the application, with its unique transport and application layer behaviors and what those imply in terms of performance. Then you focus on resolving any issues that arise because of that behavior. Then, if you still need to, you can apply traditional techniques like compression and deduplication and reduce the size to make the results of your initial efforts even better.

But if you aren't focusing on those initial efforts, you're doing it wrong. If you profile an application and find out performance degradations are caused by excessive load on the server, optimizing the WAN is not going to really help. Reducing the load on the server, however, will. While it is certainly the case that improving transfer speeds over the WAN can ensure that some of the load is alleviated by clearing out server queues faster, it won't solve the entire problem because some of the degradation is caused by excessive context switching and simple fact that is compute time sharing between threads and processes on a server. Optimizing the WAN isn't really going to address that, but reducing the number of those threads and processes required will.

See, application delivery is about the big picture - and the focal point of that picture is the application. WAN Optimization has a role to play in that picture, but it's a supporting role, just like network optimization and web acceleration. WAN optimization is not and cannot be separated from application delivery. It simply isn't a stand-alone technology - or at least not one that really enables organizations to realize real benefits with respect to performance and availability of applications. It's a piece of the larger picture that is application delivery.

For some applications – and uses – WAN optimization will provide the biggest gains in performance. Transferring large data sets such as those related to backups and DR efforts, or virtual machines in long-distance migration efforts, need the assistance of WAN optimization solutions. For others, however, such technology does very little to improve performance. That’s why application delivery focuses on the whole, on the big picture – the application and the context in which it is accessed. Without a holistic approach to application delivery you may be making one piece of the puzzle better – or you may be just spinning your technological wheels.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.