Think chip shots, not moon shots when it comes to SD-WANs

Rarely do I have a conversation about networking in which the topic of software-defined WANs (SD-WANs) is not mentioned. It's far and away the thing that network professionals care most about, even ahead of data center SDNs.

In a data center, enterprises can still people their way out of problems as there's always an abundance of experienced engineers locally available to tackle any issue, big or small. That luxury does not exist with the WAN as branch offices can be scattered across the globe, and often the best one can hope for in terms of a local resource is a branch administrator or someone who can check lights or confirm that things are plugged in and powered up.

Also, for many geographically distributed organisations, the WAN IS their business - so having an agile, dynamic WAN that enables applications to perform better is a top priority.

However, the journey towards deploying an SD-WAN may not be obvious. The known end state is relatively easy to envision - a fully autonomous WAN where applications performance is akin to a local LAN, security is integrated into the network and the network has the same level of agility as something comparable to containers.

Sounds great, but how the heck does one get there? It's like self-driving cars. The long-term vision is hopping into a car where there's no driver, steering wheel or any kind of conventional controls. The passenger simply says, 'take me home' and then watches a movie or takes a nap while the car goes on its merry way, automatically correcting for traffic congestion or other unforeseen issues. Seems simple, but where do we start?

My advice to network professionals has been to think of the journey as a series of chip shots instead of a single monumental moon shot that's so intimidating that it seems unreachable. This requires thinking of an SD-WAN as a set of smaller tasks instead of one big project and doing those tasks a step at a time instead of trying to achieve the utopian state overnight.

Here are my top ten recommended steps on how to proceed:

1. WAN optimisation. There's no sense in moving to an SD-WAN if the network has not been optimised. Without that, it's tough to understand traffic patterns and bandwidth requirements.

2. Visibility tools. You can't secure or manage what you can't see. Visibility tools will shine a light on a few existing blind spots like what cloud apps are being used, how fast the cloud is growing, where multi-media traffic is going from and to, etc.

3. Any combination of transport, including broadband. Most network engineers aren't ready to say 'no more' when it comes to MPLS. That's fine, but move to an active/active hybrid WAN where the broadband and MPLS can be fully leveraged together.

4. Dump the router. A super expensive branch router is no longer needed for local routing capabilities. Replace that router with an SD-WAN appliance or anything else that can run a virtualised router, such as a WAN optimiser. Another option is to move routing to the cloud.

5. Local internet breakout. Having cloud traffic backhauled through a central hub is a horrible waste of bandwidth and ultimately impairs the application user's experience. Instead, have the ability to identify known and trusted cloud applications in branch offices and connecting users directly to the Internet, over any combination of connections installed in step three above.

6. Virtualise firewalls. Local Internet breakout requires localised security but that doesn't mean having to deploy six-figure firewalls at every location. Instead, run a virtualised firewall on the WAN edge device that already supports routing. Alternatively, internet-destined traffic can be directed to a cloud-based security service.

7. SD the branch. Now that firewalls and routing have been virtualised, it's time to virtualise other branch services such VPNs or other security or management tools.

8. Dynamically mesh. This is getting pretty advanced, but over time orchestration tools can be used so peer-to-peer connections, like the ones required for video, can be created dynamically. The tools exist to do this today, but it does take some advanced engineering to accomplish. It's well worth it though.

9. Analyse and optimise. Collect data, analyse it and tweak steps 1-9. Network traffic changes all the time and the network must be tuned periodically.

10. Retire MPLS. This can actually be done much earlier in the process, but I'm placating the conservative folks reading this. Over time, multiple broadband connections, optimisation tools and virtualised network services can replace MPLS and give comparable or better application performance at a significantly lower cost.