The software-defined WAN, or SD-WAN, topic is fascinating, especially when considering that the networking industry has been talking about WAN transformation for decades. (Thinking back to my days as a network engineer in the '90s, I can recall discussing the need to migrate away from the inflexible hub-and- spoke architecture of the time -- and that is still the norm today!) The underlying technology has evolved from frame-relay to ATM and now MPLS, but the fundamental architecture has remained the same.
Why so much talk over the years? What's wrong with WAN design? Well, that's like asking what's wrong with reality TV -- the list is far too long for me to go into all the points. But I can easily pinpoint the main issues of legacy WANs: They are highly inflexible, inefficient, and expensive to run.
The traditional WAN uses "active-passive" connections; the backup link is only active when the primary connection fails, meaning companies pay for bandwidth they aren't using. This would be like connecting two cities with multiple roads but only allowing traffic to use secondary roads if the primary road is unavailable. Laughable, but it's the norm with WANs.
Enter SD-WAN, the solution to all problems and a panacea to all network woes associated with traffic traversing the wide area. In a software-defined network (SDN), the control functionality is abstracted up from the physical device so configuration and management can be centralized and orchestrated. That means instead of configuring the network box by box, configuration is done in one place and pushed down to all the devices simultaneously. Also, because it's software, APIs can enable applications to interface with the network directly. An SD-WAN is a WAN with the principals of SDN applied to it.
Makes sense for every organization to jump on the bandwagon and deploy SD-WAN as fast as possible, right? Well, not so fast. SD-WAN is certainly transformative and better aligns the network with digital trends, but it has many different definitions and deployment models. This makes it confusing to buyers as to what to buy and how to deploy it.
In a recent poll of network managers who were considering SD-WAN, I found the most common inhibitors to the technology's adoption are the relative immaturity of the solution providers, concerns regarding security, migration plans, and uncertainty regarding the ROI. SD-WAN has a tremendous number of benefits, and the day will come when the majority of enterprises will leverage it. The concerns, however, are certainly significant.
So how do you know if SD-WAN is right for your organization? Here are some do's and don'ts that can help with the decision.
Do Deploy SD-WAN If Network Agility Matters
The agility that SD-WAN brings is far more important than saving a few bucks on bandwidth. SD-WAN can help make a business more dynamic, and so would be a good fit for any organization that is constantly changing, must be able to add new services quickly, or has rapidly changing traffic patterns. SD-WAN enables companies to spin connections up and down, dynamically adjust network paths, and quickly add bandwidth. Digital organizations strive to be able to capture market opportunities quickly, but the business can only be as agile as the least agile component -- and in most cases, that's the WAN.
Don't Do SD-WAN for the Cost Savings
One of the big value propositions that all SD-WAN vendors tout is that the technology should save money. I've never been a big proponent of doing any IT projects for the cost savings alone, as you can always find other ways of saving money. In your looking to save money on the WAN, for example, pick up the phone, call your service provider, and renegotiate your MPLS contract. In addition, much of the touted SD-WAN savings comes from reducing the MPLS requirements by migrating from MPLS alone to MPLS plus broadband (or multiple broadband connections). However, it's my experience that companies rarely reduce bandwidth. The cost-savings argument works if the primary network is nearly maxed out. In this case, broadband is a much more cost-effective alternative to adding a second MPLS connection or adding more bandwidth to the current circuit.
Do Deploy SD-WAN as Part of a Branch Redesign
The WAN provides connectivity to the branch, and so ensuring that those links are efficient and perform well makes sense. However, the impact of WAN redesign may be limited if the branch infrastructure is a mess. Most branch offices are a mess inside with a number of appliances such as routers, firewalls, WAN optimization, path control, and other security features. The large number of appliances creates a network management headache, and results in long lead times for new services. My research shows that the average time to implement even simple changes to a WAN can be four months. To fix this problem, companies often go through an initiative to simplify branch infrastructure with either virtual appliances, multi-function devices, or a managed service. If the business is going through such an initiative, shifting to an SD-WAN at the same time is a good idea. If this isn't done, then the organization has only addressed half the problem.
Don't Do SD-WAN If You're Risk Adverse
Despite the number of vendors offering SD-WAN solutions, the technology is still relatively immature and we have few established best practices. An MPLS network may be expensive and inefficient, but the architecture is fairly straightforward. SD-WAN comprises many more moving parts, including elements like broadband WAN connections, on-premises infrastructure, cloud-managed gateways, and WAN optimization. Putting all of these together can be complex and creates some deployment risk, particularly for organizations that aren't technically savvy. This reminds me of the transition the communications industry went through when shifting to VoIP. PBXs were inefficient but simple to deploy. IP PBXs had many more components and a number of early adopters struggled with deployments. Leading-edge companies reaped the rewards of VoIP far earlier than other organizations, but they certainly experienced pain along the way.
Is SD-WAN the right technology choice? That's a question every organization must answer for itself.
It's my belief that SD-WAN will become the norm over time, much the same way that VoIP eventually won out -- as better technologies and architectures normally do. However, the migration must be done at a pace with which the organization is comfortable. Otherwise, the risks and possible downsides will outweigh the positives.