Managed SD-WAN Should Manage The Hardest Part

Managed SD-WAN Should Manage The Hardest Part

We are big fans of the SD-WAN revolution (although looking forward to the time when we stop thinking of SD-WAN as something new and different and start thinking of it as table stakes for WAN edge connectivity). One of the big benefits of rolling SD-WAN out has been making the WAN simpler to manage: setting up policies based on applications or services and their specific needs to manage the whole physical WAN at once.  So why would we want a managed SD-WAN? Even if you don’t just always outsource your WAN, there are reasons.

Most traditional WANs are managed with (at best) partial automation, typically in the form of very rare software pushes that are maybe 80% effective on the first attempt. Pushes being only 80% successful means significant manual remediation after the fact. More often, though, routers are managed as individual devices that may share some common configuration with their peers but that are, in the end, unique.  Not being a fan of the whole pets vs cattle metaphor, I prefer to refer to them in horticultural terms: we feel forced to manage our routers like prize roses when we want them to be a field of wheat.

As a new approach to WANs, SD-WAN solutions have generally been conceived and designed with the idea of uprooting the roses and planting wheat in their place.  The goal is radical simplification for management and troubleshooting, and according to our data to date, it is being achieved: our 2016/17 Cloud and Network Benchmark found 95% reduction in troubleshooting time for SD-WANs, for example.

But there is another aspect of WAN management that SD-WAN may actually make harder, something that will add appeal to the idea of managed SD-WAN despite the narrative of simplification.  The problem is rooted in another thread of the SD-WAN story: the ability to aggregate links from diverse carriers into a single WAN. This works, and provides IT buyers with more choice than ever in how they can provision connectivity into a branch as well as paving the way to connectivity that is both redundant/resilient and affordable, in more locations than ever before.

But, empowering IT to make use of many ISPs and connectivity providers in pursuit of savings and agility leaves IT with…many ISPs and connectivity providers. (In addition to whoever they are using for MPLS, which most plan to keep for many years to come.)

Most of those adopting SD-WAN have no plans to drop MPLS soon.

Managing them–both at the business level and at the technical level–has its own associated costs.  Managing a handful of companies is probably supportable for anyone; managing dozens, far less so.

So, in this at least, we see a powerful factor for considering a managed SD-WAN offering: the option of handing off the ISP aggregation and management to someone else.  Big carriers like AT&T and Verizon are used to taking this on as an additional contract term, and will have strong incentive to do so with their NFV and SD-WAN offerings.  Masergy will do this (at no markup!) as part of their SD-WAN Pro and SD-WAN Go offerings.  TeloIP, Aryaka, and other network-as-a-service providers in the SD-WAN space are in a position to do the same.  Folks intent on a DIY SD-WAN can still seek out connectivity aggregators, of course, so they too could have a single point of contact for all the various companies providing local connectivity. Several of the early adopters we spoke with last year were actively seeking such services, typically one per global region in which they were operating: one for North America, one for South America, etc.

So, despite an apparently realized promise of radical simplification for WAN management, SD-WAN can create new problems for WAN provider management.  Enterprises considering SD-WAN should be paying attention to this possibility, and considering both in-net and managed overlay solutions as they evaluate their options and make their plans.

Share this post