The Epic Failure of Stand-Alone WAN Optimization
#fasterapp #ccevent 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.
In 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.”
Wonderbar.
APPLICATIONS are not NETWORKS
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.