kantver - Fotolia
For businesses interested in saving money on their wide area network costs, SD-WAN offers a compelling return on investment.
Replace expensive, low-bandwidth private WAN circuits with cheap, high-bandwidth public internet circuits, while still achieving the same quality of experience and security for business applications. That's the "marketecture" promise, but is the financial case for software-defined wide area network (SD-WAN) so straightforward?
As with all things IT, the answer is, "it depends." Let's dive into several considerations as you evaluate SD-WAN architecture for your environment. An SD-WAN purchase isn't simply a question of cheaper circuits.
Manipulating data streams
WAN optimization, a technology many businesses use, manipulates data streams so that latency-sensitive protocols perform adequately. Using compression, deduplication, application proxies, tokenization, caching and related techniques, WAN optimization makes traffic flowing across a WAN feel more like it's flowing across a local area network (LAN).
SD-WAN and WAN optimization are not the same, nor is SD-WAN the evolution of WAN optimization, as some analysts generalize. Rather, these are two distinct -- albeit related -- technologies that companies must consider and potentially integrate.
One possible integration scenario is to pass optimized traffic from the WAN optimization appliance to the SD-WAN appliance. However, if the SD-WAN appliance cannot identify the traffic type because the traffic has been altered by the WAN optimization appliance, it will not know how to send it across the WAN to meet the business's policy requirements. You end up with WAN-optimized traffic traversing a sub-optimal path.
A variation puts traffic through the SD-WAN appliance first, and then sends it through the WAN optimization appliance, but this is architecturally flawed. SD-WAN traffic is encrypted to safely traverse public transport, and encrypted traffic can't be optimized especially well. WAN optimization appliances generally decrypt encrypted traffic, optimize it and then re-encrypt it before sending it across the WAN. While this works for HTTPS traffic, I don't know of a WAN optimization architecture that does the same for the IPsec employed by most SD-WAN vendors.
The most desirable combination of WAN optimization and SD-WAN architecture is a vendor-specific integrated offering. There are two current offerings, although the market evolves rapidly.
- Silver Peak's Unity SD-WAN offers a licensed feature called Boost. Boost adds WAN optimization to Unity in a fully integrated package.
- Riverbed Technology's SteelConnect appliances reportedly offer both the path optimization of SD-WAN with the application performance of WAN optimization.
The larger question is whether you even need WAN optimization alongside an SD-WAN architecture. In recent years, many protocols, such as Microsoft Server Message Block, have evolved to function adequately without WAN optimization. Specific application optimizations that overcome an inefficient protocol's sluggishness in the presence of WAN latency are decreasingly useful.
An acceptable user experience
In today's WAN, the primary advantage to optimization is compression and deduplication. That said, as encrypted data streams -- which are not easily compressed or deduplicated -- become more common, the benefit of WAN optimization shrinks.
Since internet circuits tend to be cheap, businesses can afford to increase WAN bandwidth compared to private Multiprotocol Label Switching (MPLS) circuits. In addition, SD-WAN can send traffic across more than one circuit at a time, increasing the available WAN pipeline even more. That begs the question: is WAN optimization actually required to achieve an acceptable user experience? This is a nuanced issue that can only be fully answered by analyzing your specific WAN traffic mix.
Private WAN contracts with early cancellation penalties could impact an SD-WAN project's return on investment (ROI). This is a critical business detail not to be overlooked. A business must push back on an SD-WAN project where there's a capital outlay, unless the operating expense goes down quickly.
It's possible to use a project like this as a tool to negotiate with service providers. Even with an existing contract, you may be able to get a new contract to drive pricing down or offer new services. Your sales representative would rather keep you in the fold for the long haul than lose you entirely. Use that to your advantage by being forthright with what you are considering, and leverage it for all it's worth.
Some organizations structure IT service delivery based on contracts and service-level agreements (SLAs) that can pose a challenge to SD-WAN adoption. If all internet circuits perform poorly at a specific SD-WAN site, you might miss your SLA obligations. The internet offers no service guarantees.
You may also encounter this SLA problem in a private WAN scenario. The difference is that in an internet-only situation, there is no room to shift blame if you fall out of SLA compliance. If the circuit is up and functional, that's all you can expect. In a private WAN scenario, you can contact support or your account representative and demand justice.
Bound by SLAs
If you are bound by SLAs, I don't mean to suggest that you should not consider SD-WAN architecture. Rather, you might keep some private WAN with strict quality guarantees as a part of the overall SD-WAN design. SD-WAN forwarders don't care if the circuit in question is public or private. While many SD-WAN vendors will fall over themselves displaying the value of the internet-as-WAN, you don't have to build it that way.
Also important to understand is that SD-WAN designs anticipate at least two internet circuits for each SD-WAN forwarding appliance to choose between. To maximize your private WAN quality of service over the public internet, you must connect at least two internet circuits at each site, ideally from different providers. This will give your SD-WAN design a more realistic chance of supporting your SLA requirements.
If you are a public cloud consumer, some SD-WAN products can improve cloud-based application performance by forwarding traffic over the most efficient internet path to access the cloud in question. Vendors such as Riverbed and VeloCloud specialize here, colocating SD-WAN gateways at critical cloud providers.
Not all SD-WAN products offer value related to public cloud consumption. Research which companies offer this feature set if it's important to your application performance mix.
Virtual routing and forwarding instances, device contexts, private virtual LANs and network virtualization all offer the ability to keep tenants on your network separate from one another. If your business has a multi-tenancy requirement, your SD-WAN vendor should support it.
Some SD-WAN vendors support multi-tenant WAN clouds, while others do not. SD-WAN multi-tenancy allows you to securely separate your tenants' traffic, as well as create unique policies, per cloud. In other words, not every tenant's SD-WAN cloud has to forward traffic in the same manner as every other. You'll need to ask the qualifying questions of your SD-WAN vendors to determine the efficacy of their multi-tenancy offering for your needs.
In some organizations, application traffic must pass through a firewall or intrusion detection system before passing through the WAN. SD-WAN traffic forwarding is governed by centrally administered policy. Some of those policy engines include a service chaining function that can meet inspection requirements.
Not all SD-WAN appliances handle service chaining, however. I use the term "service chaining" loosely here, as I have yet to see an SD-WAN appliance that offers actual service chaining comparable to what Cisco ACI or VMware NSX can offer with their encapsulation techniques. If traffic inspection via devices that are not in-line is a requirement you have, find out exactly how the SD-WAN tool you are considering accomplishes the service-chaining task.
A rapidly changing field
Most SD-WAN forwarding appliances are small, x86-based devices. They offer Ethernet ports to connect to your LAN and the WAN, but do not offer connections for traditional WAN circuits. If you require time-division multiplexer (TDM) circuit support, then you'll need to keep your existing router in place to support the SD-WAN architecture.
Keeping your existing WAN router in place as a termination for a TDM circuit is not a problem for SD-WAN, but could impact your ROI calculations. In addition, that WAN router remains on the wire as a device to be maintained and upgraded, as well as being a potential failure point. On the plus side, the WAN router configuration can be greatly simplified, since the SD-WAN appliance will manage quality of service, policy-based routing, tunneling and other complex WAN functions the router previously did.
If your organization requires 10 Gbps WAN circuits, there is no SD-WAN that has the heft to fill such a pipe.
However, this is a rapidly changing field that will eventually accommodate 10 Gbps circuits, or higher. If this is a need you have today, check with SD-WAN vendors to see what's on their roadmap. SD-WAN is projected to be on a massively growing sales arc, seeing wide adoption by enterprises. There's been a rush in the sector, with several vendors, such as Viptela and CloudGenix, establishing early beachheads. Interestingly, the technology is not new, with established vendors like Talari seeing growing interest in their proven products now that SD-WAN is a media darling.
Large organizations, such as the clothing retailer Gap, have taken on SD-WAN projects, a sign of the technology's financial value and technical viability. SD-WAN is not smoke and mirrors -- it is real and making a meaningful difference in IT shops today.
With SD-WAN, MPLS gains a new competitor
How SD-WAN helps to secure hybrid networks
What are some of your organization's biggest considerations about SD-WAN managed services?