SD-WAN Is Not Going to Take Your Job (Part 1)


SD-WAN Is Not Going to Take Your Job (Part 1)

Jun 30, 2020

The Engineer’s Corner

Bryan Kubiak, Senior Network Architect, QOS Networks

In lieu of recent events, the job market has been shaken, and lots of network managers are naturally asking this question when their businesses are looking at switching to SD-WAN.

Will SD-WAN replace my Job?

I believe if you ask the question a different way, the answer is clearer, were you hired to only specifically manage and monitor a static edge device? Almost always the answer is a simple, no.

Personally, I get why engineers typically ask these questions, especially since the sales pitch always includes some slide dedicated to SD-WAN and how it greatly reduces Operating Expenditures (OpEx) which it usually does. When you think about it, SD-WAN is another network device that needs to be managed, optimized, and monitored (sounds like we are caring for a pet!). At the branch, SD-WAN replaces the existing WAN router. In the datacenter, our customers typically run SD-WAN in-parallel to the core network. The point is, the number of devices we engineers manage remains the same.

Let’s be honest; there are parts of our job that are flat out tedious and often times an inefficient use of our time. That’s one of many areas where SD-WAN actually assists with our day-to-day job instead of replacing it.

With SD-WAN, the same networking challenges are still present—routing, application prioritization, circuit problemsthe list goes on. SD-WAN is really a new and improved form of routing, not a replacement of routing. We are not getting rid of the OSI Model; we still need network engineers trained in layers 1-7, so keep memorizing and teaching it! What SD-WAN does change is our ability to more easily configure and troubleshoot the network, which means we can be more productive in our jobs.*

  • Configure: Instead of piecing together some Ansible, Expect or Pearl script (you know who you are) to implement a network wide change, it is now 2020, so we can go to a single pane of glass, make a change to a template, and go about our day. That 2-hour maintenance window was just reduced to 15 minutes. Hows that for a productivity boost?

I also don’t want to discount the upfront planning and effort required by network engineers to ensure changes go smoothly. Said differently, network changes are not any less difficult or stressful; SD-WAN just removed the repetitive, time-consuming actions that legacy networks/technology required us to do. We still need to go through the same QA process before and after the changes are made. In our world, QA is critically important, and so we implement that as part of the full process from design to testing to validation.

  • Troubleshoot: With SD-WAN, we now have insight into what every application within your network is doing—how it’s being routed, what policy it’s following, etc. Let’s take the example a simple Apple or Windows update issue that brings a location to a standstill. With a legacy router we would hear, “site has packet loss,” and due to that packet loss, it probably took hours for the issue to reach your desk (only half kidding). The typical order of operations goes:
    • The ticket went to a Tier 1 team.
    • Tier 1 team verified and conducted initial troubleshooting on the reported issue.
    • If Tier 1 is not able to resolve within a given time, it is escalated to Tier 2.
    • Tier 2 follows the bullets above.

In a perfect world, by the time you were were notified, the problem would have fixed itself; but the world is not perfect and the issue is still on-going, and now your location has been impacted for hours or even days.

On the other hand, with most SD-WAN networks, the Tier 1 team can easily identify the source/root in the Orchestration platform—which is that someone performed an update that caused the problem. Tier 1 most likely cannot fix, but they can quickly get the issue in front of their escalations or engineering teams. At that point, it is up to us to first fix, then, come up with a permanent solution or policy that addresses this issue going forward.

SD-WAN exposes us to new technologies; as engineers we must evolve, pick up new skills (like Python), and learn how to pull information from an API. The more data we have—and SD-WAN provides lots of data—the better we can design and optimize our networks (which is why we got hired as network engineers). Uptime increases, application availability also increases, and the users are happier.

Which reminds me, I need to finish that Python video.

*One ZK Research study found 30% of engineers spend at least one day a week doing nothing but troubleshooting problems, and that 90% of the time taken to fix a problem is spent identifying the source.

The latest with QOS Networks

View All