Why Did VMware Buy VeloCloud?
The SD-WAN market is in the consolidation phase of its evolution and corporate pairings are flooding Silicon Valley. The latest news on the block is about the VeloCloud acquisition, or if we may call it VMware Velocloud.
The idea may seem strange at first given VMware’s position as the dominant player in server virtualization (Why would it want to get involved with anything WAN?), but in 2012 the company shelled out $1.2b to acquire Nicira, a startup in the software-defined network market.
The Nicira technology enabled VMware to virtualize data center networks used to support virtual servers, an important step on the way to realizing VMware’s vision of the software-defined data center. Because enterprises typically have loads of locations, it’s not beyond reach to believe VMware would want a software-defined WAN technology to stitch it together.
Oh, and if the Nicira technology — now called NSX — put VMware in competition with Cisco in data center networking, the acquisition of VeloCloud networks would enable the company to throw the other fist and try to disrupt Cisco in another core market, the WAN.
But you have to delve deeper to see what VMware will really end up with.
What is actually virtualized?
Consider VeloCloud’s efforts to virtualize the branch office. The company’s SD-WAN overlay can be used to replace branch office routers, which would give VMware a good story in competition with Cisco. Tying branch locations to VeloCloud’s cloud-based gateways makes it possible to simplify branch infrastructure.
However, VeloCloud only virtualizes the network edge, not the underlying transport beyond the gateways. VeloCloud relies on the inherently flaky Internet and legacy MPLS to connect Point A to Point B over the long haul. While there are benefits to virtualizing the edge, VMware will not be virtualizing the WAN itself.
Why does that matter?
You have to consider the core developments driving interest in SD-WAN in the first place. Enterprise backbones that rely on legacy MPLS are increasingly irrelevant as:
- Bandwidth demands are skyrocketing — up 155% in the Americas and more than 240% in the Asia/Pacific region — as companies connect more devices, rely more on video, and pour money into digital transformation efforts.
- More traffic emanates from and terminates at mobile devices.
- Enterprises shift compute workloads to the cloud. By some counts, almost half of enterprise traffic today uses HTTP and HTTPS, the protocols that support cloud/SaaS applications (see State of the WAN, 2017).
MPLS networks are too static, too hard to manage and too expensive to meet the needs of this new reality, hence the explosive interest in SD-WAN. But – and this is the big point – not all SD-WANs are created equal. The trick is to find a solution that can do the job more flexibly and for less while maintaining service levels required for business-critical applications.
The core difference
SD-WAN technologies that simply rely on the Internet for long-haul transport leave themselves open to service vagaries stemming from congestion, latency and packet loss, even with today’s advanced forward error-correction technology. That translates into wide swings in application performance and, worse yet, lengthy response times that handicap end users.
The 2017 State of the WAN Report collected data from more than 5,000 locations in 63 countries to measure the performance of file transfers and cloud/SaaS applications over the public Internet. Remarkably, TCP application response times can be as high as 40 seconds and have a variation of nearly 200%, depending on the distance between sites.
While regional Internet links, particularly within the US, can measure up, long-haul connections, particularly to other parts of the world, don’t fare well. The tests show, for example, that links between San Jose and Chicago had an average response time of 202ms and a low response time variation of 8%. The lowest quality link – San Jose to Shanghai – had an average response time of around three seconds and an average response time variation of 150%.
So, now that VMware has acquired VeloCloud to virtualize the WAN, all it will really be doing is virtualizing the edge and ignoring the biggest problem, which is the middle mile.
Think of it this way: If you were trying to get from San Francisco to Silicon Valley during rush hour, would you opt for the highway with all those on ramps feeding in variable streams of crippling traffic or get onboard an Elon Musk Hyperloop?
In the SD-WAN world, the only way to approach the efficiency of the Hyperloop is to control that middle mile instead of relying on the public Internet.
Virtualizing the Complete WAN
Aryaka has built a global private network tightly coupling 30+ international points of presence. It manages the complexities of that WAN and serves up access in the easy-to-consume fashion that has become the hallmark of SD-WAN technologies. It has even built in WAN optimization, so less bandwidth is needed to accommodate your needs compared to traditional network options.
The result is a network that delivers all the promise of SD-WAN but with a dedicated undercarriage that makes it possible to support the SLAs required by your business-critical applications.
A recent test compared the results of global application response time over the Internet versus a private network. In this experiment, it took about 1.185 seconds to transfer a 100KB test load from Dallas to Dubai over the Internet and only 0.375 seconds using a private network, such as Aryaka’s Fully-Managed Cloud-First WAN. The difference between London and Dubai was even more pronounced: 4.24 seconds using the Internet and only 0.19 seconds using Aryaka’s Cloud-First WAN.
Though VMware has acquired Velocloud Networks, Inc., it is safe to assume the evolving SD-WAN market will continue to see its share of consolidation. With many SD-WAN players focused on virtualizing the edge, keep in mind that virtualizing the middle mile is harder to do and where the biggest business advantage lies.
Find out more about the benefits of using a Global SD-WAN to accelerate the middle mile.
About the author
