SD-WAN has the potential to drive down costs and make organizations more agile. But what about service level agreements (SLAs) for critical applications?
Network virtualization has been a prominent narrative in the telecommunications industry, with network operators and vendors alike working hard to extract the control plane from the underlying dataplane. But, unlike using virtual machines in a data center, this concept is proving to be quite difficult to apply with traffic traversing a wide area network (WAN), because the virtual resources are geographically distributed. A subset of virtualization, software-defined WAN or SD-WAN, is a particularly hot topic at the moment—both for network operators and the enterprise customers they serve.
For enterprises, the appeal of SD-WAN is its potential to drive down costs and create a more agile and centralized control and management layer. It’s an order of magnitude cheaper to send application traffic over the internet than over dedicated (private line) links; however, it’s also not possible to offer a service level agreement (SLA) over the public internet for critical applications. SD-WAN make it possible to separate applications so that only the most critical ones are directed over the higher-performing (more expensive) dedicated links and the lower priority apps can be directed over lower-performing (lower cost) links such as the internet. This changes the WAN dynamics, going beyond a design that merely calculates how much bandwidth is consumed, to designing the WAN based on how the bandwidth is actually being consumed. Obviously, this is a significant reason to adopt the technology, even if doing so doesn’t exactly free enterprises and service providers from vendor lock. But, there are a couple of key reasons why SD-WAN adoption during 2018 will be a slow ascent rather than a rocket launch.
Operational tools and SD-WAN
A one-size-fits-all approach doesn’t really apply to SD-WAN, because different verticals have different needs. Communication service providers (CSPs) may need multiple solutions from their vendors. In this sense, SD-WAN creates an even worse vendor lock situation than traditional networking solutions. Operators will need to invest a lot to integrate tooling, visualization, monitoring, and management. This cost will delay adoption.
Relatedly, note that SD-WAN has not freed enterprises or service providers from vendor lock-in. There is still one vendor with one centralized controller managing all the boxes. Worse, there is now no interoperability between vendors; unlike traditional IP routing technology, where routers from different vendors could ‘talk’ to each other and exchange routing tables, etc., there’s no way to acquire interoperability between solutions from different SD-WAN vendors .
Yet, this isn’t stopping service providers from adopting SD-WAN; it’s in their best interest economically to roll out new services to meet their clients’ needs, even if that means vendor lock-in. SD-WAN is an opportunity for service providers to recover some of the revenue lost from declining private line service revenue and also improve their operational efficiency by taking advantage of centralized policy management, etc.—and even offering this to their customers for a better experience.
Organizational structure and SD-WAN
Even though networking and IT technologies are converging into single-box virtualized solutions, stove-piped organizational structure between IT and network management still persists and is slowing operationalization of SD-WAN. Resolving this will take time. Additionally, with SD-WAN controllers being cloud-hosted, the whole network stack must be managed by a unified team. Organizational questions like “who owns this problem?” when an issue occurs need to be addressed appropriately. Again, this will take time.
A key point to keep in mind about SD-WAN is that it’s not the same as software-defined networking (SDN); instead, it’s really just a new way to route enterprise traffic. Rather than using traditional Layer 3 IP address-based routing technology, traffic steering or “routing” decisions are being made that include policies for Layer 7. This application steering being driven by user policy is the tool used to decide which application traffic traverses which links.
As an overlay network tunneling above the underlying Layer 3 infrastructure—tagging packets based on the specific requirements of applications—SD-WAN measures performance using end-to-end metrics. If requirements aren’t being met, traffic is re-routed. The downside of this overlay approach is that there’s no segmented view of the network underneath, and thus no way to know how or why a problem originated—and no way to actually fix underlying issues. It’s like a doctor telling you you have a problem and saying “it doesn’t have to be this way,” but not offering a remedy.
With Accedian’s best-in-class active network performance monitoring solution, SkyLIGHT VCX™, we provide that underlay network performance visibility. VCX can pinpoint the location of a network performance problem, whether the operator is using SD-WAN or traditional infrastructure. Additionally, Accedian PVX, a solution acquired from Performance Vision, can diagnose whether the issue is with the network, server infrastructure, or application code itself. It does this for every user, flow, transaction, link and application, identifying within seconds the root cause, using a single lens capture of wire data.