CloudGenix CEO Claims WAN Optimization is Dead
In a recent interview with CRN, the CEO of CloudGenix, Kumar Ramachandran, was asked for his opinion of the WAN optimization market. Kumar’s response, and I quote, “The reality is that the WAN optimization market is a dead if not dying market.” Now, to be fair, he wasn’t the first and certainly won’t be the last person to make such a claim. However, I found his reasons substantiating such a claim the most interesting so let me share them with you.
The first reason Kumar presented was the technology for optimizing SaaS applications (e.g. Exchange Online) is different than optimizing on-premise applications (Exchange server). There may be some truth to this because an on-premise application may be using HTTP rather than HTTPS when it’s in the cloud. However, I have yet to come across an application whereby the SteelHead was able to optimize it when it's on-premise but failed to do so in the cloud. The core protocol used by the application is typically the same whether it’s on-premise or into the cloud. For example, Outlook uses the MAPI-over-HTTP protocol whether it’s connecting to an Exchange server on-premise or Office 365. Furthermore, with HTTP being used as more of a transport protocol like TCP, the likelihood of not being able to optimize an application is very slim. Therefore, the question is not whether one could optimize an application but rather, how well could one do it?
The second reason Kumar presented was the commoditization of network-level optimization techniques. Once again, there is some grain of truth to this. When we first shipped the SteelHead product in 2004, most end systems didn’t support enhancements such as TCP window scaling. Today, this is very much the standard on every operating system. However, we have numerous network-level optimization techniques that are built into the SteelHead product. Some of these techniques are defined by the IETF (e.g. RFC 3649 HighSpeed TCP for Large Congestion Windows) or other standard bodies (e.g. SCPS - Space Communications Protocol Specifications) while other techniques are proprietary to Riverbed such as MX-TCP. As such, SteelHead has the capability to operate well in environments whereby the underlying network is less than optimal. These techniques are even more critical today because customers are looking at leveraging the Internet as a transport.
A good question to ask at this point is: how can CloudGenix, or any other pure play SD-WAN player for that matter, help with applications in suboptimal network environments with high latency and packet loss? (hint: Forward Error Correction is not the solution)
The last reason Kumar presented was that deduplication does not work with encrypted traffic. This is absolutely true especially if one does not have the capability to decrypt SSL like CloudGenix. However, as someone who proclaimed to have helped define and build the WAN optimization industry, Kumar must be aware of the fact that even his ex-employer, Cisco, has the capability to decrypt SSL traffic using a trusted man-in the-middle technique. In 2006, we invented the technique for dual-ended SSL optimizatoin and we’ve kept up with this development since. Earlier this year, we became the first vendor to announce end-to-end support for TLS 1.2 with ECDHE ciphers with dual-ended optimization. As of October 2016, we remain the only vendor to support TLS 1.2 with ECDHE ciphers for dual-ended optimization.
Here’s another good question to ask is: how can CloudGenix help with insufficient bandwidth if the majority of the traffic is SSL encrypted?
I decided to have a little bit of fun and prove the point that it's possible to optimize encrypted traffic. I configured the SteelHead to optimize the "CloudGenix SDWAN Mixer with Packet Pushers at Cisco Live!" video on YouTube. As you can see from the screenshot below, the 8MB traffic was reduced to 18KB on second and subsequent viewings. Why is this important? It's important because of the ever increasing demand of bandwidth for video on the Internet. Imagine there were 10 people who viewed this video, that would be 80MB of traffic vs 180KB. Or to put it another way, 80MB would have traversed a CloudGenix network but only 180KB would have traversed a SteelHead network. Massive difference.
SD-WAN vs WAN optimization
There is no denying of the fact that SD-WAN is a disruptive technology. After all, this is the reason why Riverbed invested in this area as well. However, unlike the myopic view of the pure play SD-WAN players out there, we view SD-WAN as one key component of the entire infrastructure. SD-WAN enables agility and that’s good but it’s not sufficient. What good does it do if a branch can be provisioned in hours only to find the application does not work well due to the underlying network? Or how would one go about troubleshooting slow SharePoint performance running in Azure? These are questions that SD-WAN alone cannot solve but it’s something that we can help with by leveraging the multiple products that we have in our portfolio.
I included the pie chart above showing three key areas that we're focused on: agility, visibilty, and performance. SD-WAN falls into agility category while WAN optimization falls into the performance category and the two complement each other very well. Furthermore, there is the visbility category providing network and application performance monitoring which is equally important within the infrastructure. While Riverbed started out as the WAN optimization company, the reality is that we've evolved into a trusted advisor role for our customers providing solutions to their entire infrastructure both on-premise as well as into the cloud.
With that, let's leave the one-trick ponies behind as we move forward into the cloud.