They said SD WAN was easy!
One of the promises people make about SD WAN is that it will make our lives easier. It will orchestrate the network, choose routes that give the best performance, distribute patches and updates automatically and replace the command line with a graphical interface.
Download our excel template to help you decide on DIY vs Managed SD WAN
People are sometimes told they can move to SD WAN and then manage the network themselves, because SD WAN makes it easy to deploy and manage it.
- Is this true?
- Would a DIY or a managed SD WAN suit your business best?
- How should you decide?
Let's explore some drivers that will affect your choice, and some questions that will help you decide.
Two SD WAN characteristics particularly influence the choice
Many of the factors driving the choice between Managed and DIY come from two characteristics of SD WAN.
- The first is that SD WAN is an overlay; you still need a network beneath it.
- The second is that SD WAN hides complexity but does not completely remove it.
SD WAN is an overlay; you still need an underlay
An SD WAN network starts with devices and the software to control them, which are known as an overlay. It's an overlay because it sits above your MPLS, VPLS, Internet or other connectivity, which in turn is known as the underlay.
When you move to SD WAN, this underlay does not go away. It still needs to be procured, installed, configured, monitored, repaired, changed, billed and paid for.
That means managing carriers (who each have their own names, definitions and processes for services), placing circuit orders, project-managing installations, and dealing with faults. That's on top of designing the underlay in the first place, monitoring it and maintaining its performance.
Someone has to do that work. The question of WHO does that work goes to the heart of your choice about DIY vs Managed SD WAN.
Self-Driving WAN
One major vendor positions their SD WAN as Self-Driving WAN, because of its ability to adjust the way that it runs the network to meet your business intents.
That is a great analogy, especially if it’s self-navigating, too. If we upgrade to a self-driving car we could just imagine being able to dispense with the chauffeur!
If a self-driving car needs no chauffeur, does a self-driving WAN need no management service?
Well, there’s more to a running a car than just driving it around. If we fire the chauffeur, then we still have jobs to do to keep our self-driving car fuelled and on the road.
What will still need doing?
With a self-driving car, we'll still have to buy fuel from the same filling stations that we take for granted today. If it’s an electric car, we’ll still have to deal with all the charging networks and their accounts. Without the chauffeur, we'll now need to get out of the car to fill up and to pay ourselves.
Would that be so bad?
No, not on the face of it. However, back in the real world we buy a lot of things from carriers, and we know its not always pain-free to deal with them (especially multiple carriers). So, what if our chauffeur had been handling the refilling or charging of our car, what if we fired him, and then found that:
- Every fuel station has a different process to get the fuel each time?
- They each need you to set up a separate account, and send you a separate bill?
- They ask you to pay in different currencies – with some not offering to speak your language?
That could be quite a lot of hassle.
If our chauffeur had been dealing with all of that for us, then we might miss him when he's gone.
What about the things that other people do for us?
We also need to keep our new self-driving car on the road.
We still need a garage, a mechanic and a spare parts department.
Will still need a breakdown company for when it won't start in the morning, and a recovery truck and body shop to pick up the pieces after a crash.
And we need someone to deal with all of those suppliers, and with all of their admin.
Dispensing with a managed service is like firing the chauffeur, the garage, the mechanic, the spares supplier, the breakdown company, the recovery truck, the body shop - and the manager who administrates all their work for you.
If we had to pick up all of their jobs, then we may have little time left to use the car!
So, this begs some questions:
- What are ALL the jobs involved in running your WAN today?
- Who is doing them TODAY?
- Who do you want to have doing them AFTER you move to SD WAN?
By the way, when you pick up your new self-driving car, you can’t just sit in the back; you’ll be behind the wheel to check everything is ok, start the engine, set up the Sat Nav and keep a watch out for problems.
However, if you keep the chauffeur and the rest of the support crew, you can safely get in the back and get on with some real work while the car gets you quickly and reliably to your destination.
That's one reason that Enterprise WAN managers use a managed service; so that they can focus their scarce resource on adding value rather than running the WAN.
SD WAN makes your network look simple, but it's complex underneath
SD WAN prides itself on simplicity, presenting you with a simple view of your network, and promising to make it simple to manage. But beneath that simple view lies a network that is just as complex as it was before, probably more so.
While the overlay makes things look simple, there is a lot going on under the hood. And while an SD WAN user interface makes things easy to change, the implications of those changes can be far-reaching. This creates new risk for teams who previously delegated such changes to the management service.
Turning to the underlay, this will tend to become more complex with SD WAN.
Why more complex?
Among other things, the underlay can be more complex because SD WAN encourages you to:
- Have multiple circuits at each site;
- Mix internet with traditional network technologies;
- Route traffic dynamically.
With SD WAN, the underlay still needs to be designed and sized to support the traffic and performance that your applications need. When things go wrong, the problem still needs to be identified and rectified. With complex and intermittent problems this work can be non-trivial, and it's often outside the scope that SD WAN can deal with.
To illustrate, a large global geo-science business recently reported that their new SD WAN suffered from poor latency. The SD WAN overlay presented global connections as single hops with low latency.
However, this masked the reality of multiple physical hops and sub-optimal transatlantic hops that led to very long total latency.
It took traditional skills to identify and fix this problem, and at best, SD WAN didn't help because it obscured what was going on.
The automatic gearbox in your car presents you with a very simple experience, but it hides great complexity. Similarly, SD WAN presents a simple view of your network, but it, too, hides great complexity.
Complexity means that, for the whole network to perform well, network expertise is still required at design stage, during deployment, during post-deployment tuning, and when complex problems arise in-life.
Again, someone has to do that work, and the question of who does that work goes to the heart of your choice about DIY vs Managed SD WAN.
