One of the promises made of 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.
People have sometimes been told they can move to SD WAN and manage the network themselves, because SD WAN makes it easy to deploy and manage it.
Can you move from a managed WAN to a DIY SD WAN?
Here are some thoughts that explore that question, and some questions that will help you decide.
Many of the drivers for choosing between Managed and DIY come from two SD WAN characteristics.
Want to save this guide for later?
No problem! Just enter your email address and we'll send you the PDF of this guide for free.
The devices and software in an SD WAN network are known as the overlay. It's an overlay because it sits above your MPLS, VPLS, Internet and 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.
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.
Really? 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 that’s not always pain-free. So... what if we fired the chauffeur who had been handling our fuel and our charging, and then we found that
That's 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:
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 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:
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 well 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. 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.
When you move to SD WAN, you will be taking on a network that remains complex despite SD WAN, and one that still retains the underlay that you’ve always had.
Here are three decisions that will need to be made:
Here are some questions to help you decide whether you want to do this work yourself or whether you would prefer a managed service to do it for you.
With a DIY SD WAN you would need to design the network and manage not just the devices and software, but also the circuits, carriers and underlay performance. It might be easy to roll out changes using SD WAN but you still need expertise to handle the underlay and deal with subtle performance issues or difficult problems arising.
Do you want to manage the procurement and provision of circuits across multiple countries, multiple carriers and multiple technologies, in multiple currencies and languages? SD WAN could make this work more complex, because it will encourage multiple circuits per site, across multiple technologies, possibly from multiple carriers, maybe in multiple languages, and the need for a new security regime as you increase your exposure to the internet.
A WAN project manager will plan, lead, co-ordinate, schedule and document the deployment of your SD WAN network, perhaps also the transition from your existing network. An experienced WAN project manager will know how to deal with a huge range of issues; procurement of hardware and licences; co-ordination of deliveries and engineers, managing wayleaves, and dealing with carriers when circuits are delayed and can make the difference between success or failure. Find out more in our article How to choose between DIY and Managed SD WAN.
Many in IT see the WAN as a critical resource for which a responsible engineer rather than a janitor should attend to install, test, liaise and document your SD WAN device installations and support visits. If you move to a DIY model you’ll need to set up deployment and logistics processes, train (potentially hire) engineers, manage workload peaks and troughs, holiday and sickness cover, as well as training to mitigate regular experience if WAN is not the day job.
Our article on Managed vs DIY SD WAN explains why you should have a 24x7 helpdesk even if you don’t operate around the clock. You need a minimum of three shifts to handle 24-hour working, and then cover for holiday and sickness and then additional resource to support the different skills of first, second and third line agents. That’s probably a minimum of five people. Someone will also need to deal with management, keeping skills up to date and succession planning. The cost for this should be part of the calculus for choosing between Managed and DIY.
If you operate in locations where the prohibition of encryption or other constraints prevents you running SD WAN then you could find yourself running a more traditional network in those locations. It is worth considering whether those situations could apply to you, along with your attitude towards managing them yourself.
A Managed Service provides expertise to deal with problems and relieves you of the ownership and stress of those problems. Since SD WAN adds the complexity of multiple circuits, dynamic path allocation and a new attack surface, it is arguable that a managed service could be more attractive internet with SD WAN. It is worth considering your attitude towards ownership and accountability for keeping the network running and performing 24x7.
Cloud connectivity comes with design choices and management implications, such as optimising the cost for egress from the platform. It is helpful to consider whether you would prefer to make the design decisions and handle the work yourself or use a managed service.
Most businesses have limited IT resources and want to deploy them in the most effective way. A common line of reasoning is that the IT Team should concentrate on things that only they can do, and have the WAN managed by experts.
It would help to identify all the reasons why you're using a managed service today and decide which would still apply with SD WAN. What do you value in your current Managed WAN Service?