Despite widespread interest in software-defined networking, enterprise adoption of SDN has been slow. With all the attention on software-defined WAN, I wonder if it can be a catalyst for SDN adoption in the enterprise -- in other words, a "killer app."
SD-WAN augments a traditional MPLS network with broadband and other networks plus intelligence from a controller that directs traffic to the appropriate path. It combines classic WAN technologies with SDN features such as network automation to enforce policies.
The rise of SD-WAN is partially a reaction to the changing enterprise environment: There are more SaaS applications, increased use of network-sensitive apps like voice over IP (VoIP) telephony, and challenges in making the existing infrastructure adapt to these needs. People want a modern WAN work to meet these needs while staying within budget.
Many elements associated with SD-WAN have been around for many years, such as the ability to combine the public Internet with MPLS or VPN, classify and steer traffic where it is best suited, or to use overlays to tunnel over multiple networks. WAN optimization for compression and caching has been widely deployed for years. Dynamic Multipoint Virtual Private Network (DMVPN) delivered some of these capabilities, but is a combination of technologies, as opposed to single product or feature.
But SD-WAN isn't just a repackaging of old technologies. There are some innovations such as central controllers, built-in analytics, network service provisioning and orchestration. The code is freshly written, and parts are cloud-based. Centralized policy management and security features such as app firewalls, segmentation or key management are often included. Together, these help deliver a modern WAN with SDN capabilities.
With SD-WAN, startups and traditional networking vendors alike have packaged a variety of technologies into an easy-to-deploy solution that reduces the need for extensive configuration by end users, and the result is marketed with a clear ROI.
Packaging matters since makes it simplifies the purchase process. A product from a single vendor is easier to buy compared to a solution comprised of software, hardware devices and professional services from multiple vendors. Furthermore, a single supported product is easier to deploy and support for the mainstream users’ skill sets since there is a single source of training or documentation. CIOs often state that matching a solution to an organization’s skills set is a key requirement for adopting products.
Startups such as Aryaka, CloudGenix, Pertino, VeloCloud, Viptela and Talari Networks offer SD-WAN products. Established vendors with WAN products such as Cisco (with iWAN), Citrix, FatPipe, Ipanema (part of InfoVista), Riverbed and Silver Peak Systems also compete in this segment.
WAN modernization obstacles
If you already own traditional WAN building blocks with the right features, it’s possible to redesign it to meet current needs, but you may encounter these obstacles:
- Systems integration difficulties: Modernizing a WAN requires redesign. IT management may say, “You have the building blocks, so please just make it work.” However, it’s not always simple to do, or get budget to pay for professional services.
- Organizational boundaries: WAN technologies may be paid for by both central and remote office IT budgets, and changes require buy-in from many parties.
- Timing is not right: Some groups be reluctant to fund modernization since they need to wait until network circuit contracts are up for renewal or existing hardware gets refreshed.
An SD-WAN solution makes it easier to overcome the system integration objections since you can point to a single product for WAN modernization But how does one overcome the timing and organizational objections?
SD-WAN products are sold with a clear emphasis on ROI as opposed to a set of technologies. From the perspective of CIO, if a product or service saves money or improves service levels, then it makes sense to consider it, regardless of how it matches with the upgrade schedule or where the budget is controlled.
The savings are realized in two main ways. One is to limit the growth of adding MPLS circuits as traffic needs grow by augmenting it with a low-cost public Internet link for carrying low-priority traffic. It’s also possible to reduce MPLS circuits if they were deployed in excess of the current needs and can be split into a combination of fewer MPLS circuits and broadband links.
When server virtualization took hold in the last decade, there were two ways in which purchases were justified. Server containment, which is to slow down the rate of physical server sprawl, and server consolidation, which is transform existing physical servers into VMs. It was much easier to sell virtualization based on server containment, as opposed to doing physical server conversion.
The same may apply in SD-WAN: As end-users adopt more cloud apps and require more bandwidth, SD-WAN may be used to control the growth of MPLS circuits and steer traffic to the cloud, instead of to the central datacenter. It’s a form of containment.
So is SD-WAN a killer-app for SDN? It may be too bold to proclaim it a catalyst that suddenly brings SDN into the mainstream. I expect the strong pull to modernize WANs will help the adoption of SD-WAN, and that in turn will deliver SDN capabilities into enterprises. Once deployed, SDN technologies such as automation and policy-driven control will prove their value and serve as examples for use elsewhere in the data center.