posted on Monday, July 19, 2010 1:04 PM
Where you are going has a huge impact upon the mode of transportation that you choose to use. If you are going to the neighbor’s house, you tend to walk. If on your way to town or downtown, you tend to take
a motorized vehicle. Out for a leisurely trip around the subdivision? You are likely going to ride a bike. Going to another continent, probably a plane, maybe a ship… You get the idea.
Several years ago (while working for Network Computing) I reviewed WAN Optimization products, with an eye to file transfer acceleration. Interestingly, F5 decided not to participate in that review (I won’t conjecture why, they weren’t alone). At the time, all WAN Optimization was treated pretty much equally. Tacit Networks (later bought by Packeteer, who was subsequently purchased by Blue Coat) was pretty zeroed in on remote office access and acceleration, but all of the other vendors I looked at were, at the time, treating all WAN Optimization greatly the same.
These days that’s far from the truth, with different feature sets of WAN Optimization products aimed at DC-to-DC or DC-to-Cloud versus DC-to-remote office. Talking over the differences and how they influence product development with one of our uber-smart PD people spawned some intriguing points that make these product sets completely different, though they may well use the same set (or overlapping sets) of functionality.
Back in the day, Tacit networks had approached the problem by going very Microsoft heavy. They tied their file acceleration to Microsoft technology, along with several other “add-on” functionality bits. It made their product unique, but overall the product didn’t fit well into our review because we were looking at something more acceleration focused and they were more general remote office focused (you could accelerate a Windows-shared printer in the DC, for example). These days the industry has a more firm grasp on what it takes to serve a remote office versus a remote DC, and the devices share a decent amount of functionality while still targeting different market needs.
The thing that got this blog started was pretty simple, but I had not paused to consider. Remote office devices pretty much require fail-to-wire functionality because there is no other route to get out of most remote offices, and there is often no IT staff at the remote office to make the routing changes. DC-to-DC devices however do not require fail-to-wire because there are alternate routes out of the building and plenty of staff to jump if issues come up. This issue becomes less clear if you consider the inclusion of security functionality in WAN Optimization devices. Do you fail to wire on a device that is supposed to be providing edge security? And if not, what are the business implications of rejecting all connections if something goes wrong with the box. This conundrum pretty much guarantees that if the application/connection is important enough to put a WAN Optimization device onto, you should probably get a redundant pair right at the outset.
Never easy for the IT person, is it? There have been some great changes – like integrated security and all-in-one QoS – that do make your life easier, but they increase the workload… At a minimum on initial configuration and likely off-and-on over the life of the product. But if it keeps you from buying more bandwidth, secures the connection without burden on servers, and handles QoS issues by balancing how much bandwidth a given protocol/app can use up… A few hours setting it up and tweaking configs is reasonable, no?
No doubt there will be more to come on similar topics, I have a ton of notes from these conversations, and there’s some cool stuff hiding in there.
Related Articles and Blogs
