The delivery challenges every SD-WAN project must consider

It’s no secret that enterprises are looking at SD-WAN as the means for evolving their networks. The technology improves on MPLS with better agility, more capacity increased resiliency and, of course, cost savings. Those advantages are in much need; just ask anyone who’s runs an MPLS network. They’ll tell you about its high costs, long provisioning times, and susceptibility to last-mile failures.

But keep listening and MPLS customers are also bound to talk about the technology’s rock-solid reliability. They’ll hate the price and delays, but they’ll love their SLA-backed performance and how the MPLS provider takes care of everything — the last mile connectivity, managing the backbone, consolidated billing and more.

The properties of MPLS services may be disliked but the packaging is still widely admired. And since networking professionals are conservative by their nature, there’s a big draw to stick by MPLS. Yet, religiously clinging to the “proven” and “known” is a good way to kill any real WAN transformation effort — and leave your company in the dark ages of networking.

Thinking through the “packaging” then is essential for any WAN transformation. This means considering a range of issues, such as last-mile procurement and post-deployment management, which were inherent to MPLS.

Procuring both primary and secondary local ISPs

Arguably the biggest change from SD-WANs to MPLS in terms of those “packaging services” is in the last mile. Now enterprise will need to get involved with procuring, managing and paying for Internet last mile access around the globe. MPLS pundits (read the carriers) will tell you that’s an enormous hassle anyone running a global network should studiously avoid at all costs — at least that’s the popular refrain.

The reality is a bit different. While there’s no question the one-stop shop of MPLS made global build-outs easier in many ways, it’s also true that last-mile procurement may not as big a hurdle as many think. For one, your organization might already be juggling multiple last-mile providers. After all, best practice for legacy WANs is to connect branch offices with a primary MPLS link and an Internet backup. Some local ISP needs to be providing that line for backup.

What’s more multiple providers will gladly assume the burden of aggregated contracting, invoicing and billing. Expero, Brodynt, and Global Internet come to mind. In fact, many are the subcontractors global telcos will use to solve their own last-mile issues. Last-mile procurement may not be a show-stopper for SD-WAN, but it is something that must be carefully considered.

Post deployment management and trouble-ticketing

MPLS services are fully managed network services, which means your MPLS provider handles the network monitoring and troubleshooting — for a fee, of course, and often only after opening (and waiting on) a trouble ticket. How will that work with SD-WAN and multiple ISPs? A lot of it depends on the SD-WAN architecture. In principle, SD-WAN helps you get away from the fully-managed model of carrier services. The extent to which you move towards self-service, on one end of the spectrum, or full-managed, on the other end, will depend on the SD-WAN architecture.

If you choose to do the deployment yourself with SD-WAN edge appliances, you’ll most likely have to shoulder the responsibility for troubleshooting networking issues. Depending on company size, IT expertise, and established processes this may not be such a problem.

As for services, SD-WAN services offer a different approach from the fully-managed carrier services. A co-management model allows both customer and provider to troubleshoot the network. It blends the benefits of self-service with a simple management console, and strong support and operations capability for advanced troubleshooting.

Delivering co-management requires suitable underlying networking and security architectures. The SD-WAN technology is part of that solution, but for co-management to really be effective, it should include the security infrastructure as well. Many SD-WAN services, where carriers integrate and package third-party SD-WAN and security appliances as a service, are fully-managed or only provide co-management for the SD-WAN infrastructure not security. Instead, they will offer monitoring consoles for viewing and reporting on SD-WAN traffic flows but require ticket submission to change the network.

SD-WAN delivered as a service (SDWaaS) where SD-WAN and security are converged into a software-based, cloud service (not a set of appliances on-premises or in the carrier network) will offer co-management in both domains. They put the end-to-end monitoring on the SDWaaS provider, but the security and SD-WAN management on the user. Since they provide the edge SD-WAN, SDWaaS providers can see when branches go down or are affected by an ISP outage, and alert you accordingly. The provider is maintaining the underlying network and infrastructure for all users; you’re responsible for the management of your own network instance.

The how’s of SD-WAN

SD-WAN is a promising technology foundation for the future WAN, but any successful global deployments means carefully thinking though operational issues.

How will you procure last-mile connectivity without been awash in invoices in five languages and 10 different currencies?

How will you monitor, manage and troubleshoot those providers in a way that meets (or exceeds) your company’s experience with MPLS?

Luckily, there is an enormous range of SD-WAN options to meet a diverse range of needs. Selecting between them involves understanding how best any solution can address the “packaging’ issues without compromising on the core drivers for SD-WAN — speed, agility, capacity, and cost savings. And that means looking past to the organizational beliefs of the “proven” and “known” solutions or “That’s the way we’ve always done it” to the benefit for your business. Because in this decision around WAN transformation, religion has no place.