What to Look For in Managed SD-WAN Services

In my last blog entry I pointed out that 2017 will be an important year in terms of the adoption of SD-WANs. In that post I discussed some of the technical characteristics of SD-WAN solutions that network organizations should pay close attention to, since these are the characteristics that will determine whether or not these solutions are successful.  I am going to use this entry to discuss some of the things that network organizations should look for in 2017 to determine the likely success of managed SD-WAN solutions.

The interest in managed SD-WAN solutions

The last few months have seen a large number of Communications Service Providers (CSPs) announce their plans to offer managed SD-WAN services. This includes Tier 1 CSPs such as AT&T and Tier 2 CSPs such as Masergy.

The interest that CSPs and others have in offering a managed SD-WAN service is matched by the interest that network organizations have in deploying those services. The 2017 Guide to WAN Architecture and Design included the results of a survey question in which the respondents were asked to indicate which of three WAN implementation options their organization was likely to implement. The three options were: Do-it-Yourself (DIY), Managed Service, and Network-as-a-Service (NaaS). Multiple responses to the question were allowed.

The results of that survey question were:

  • DIY: 54%
  • Managed Service: 42%
  • NaaS Offering: 27%

These survey results show that there is strong interest in each of the three implementation options, with the bulk of the interest being in either a DIY or a managed service solution.

Key characteristics of a managed SD-WAN service

As mentioned, in the last blog I discussed some of the technical characteristics of SD-WAN solutions that will determine whether or not these solutions are successful. Those characteristics include the overall solution architecture as well as the range of performance, security, extensibility, and management functionality that the solution provides. Those characteristics are important independent of how the solution is implemented; i.e., DIY or managed service.

If the organization is implementing an SD-WAN on a DIY basis, it has to be concerned with the ease of implementing and operating the solution. If the organization elects to adopt a managed SD-WAN service, it has to be concerned with the strength of it’s ongoing relationship with the CSP.

The most common way that a CSP will offer a managed SD-WAN service is that they will combine functionality provided by an SD-WAN vendor with the WAN functionality that the CSP currently provides. The CSP will likely continue to offer whatever SLA it currently offers for its MPLS offering. These SLAs usually include factors such as time to install, availability, and a couple of end-to-end performance metrics such as delay and jitter. The SLA that Verizon offers for its Internet dedicated access service typifies what users can expect to see in an SLA for a managed Internet service. It includes parameters such as time to install, time to repair, and availability. It does not include any performance parameters.

Since CSPs are just beginning to offer managed SD-WAN services, they will be reluctant to commit to much more than their current SLAs for MPLS services and Internet access. Network organizations, however, should work the CSPs for some commitment on the functionality that is specific to the SD-WAN appliance that the CSP is using. For example, assume that the managed SD-WAN service has optimization functionality to improve the performance of chatty protocols, or to reduce the amount of time that it takes to transmit large files. When negotiating the contract for this service, network organizations should work with the CSP to get some commitment relative to how well this optimization functionality will work in production. In similar fashion, if the managed SD-WAN service dynamically routes and reroutes traffic over multiple WAN links based in part on the performance characteristics of those links, then network organizations should also work with the CSP to get some commitment relative to how well this functionality will work in production.

I believe that the currently available SD-WAN managed services are just the first generation of such services. As such, it is reasonable to expect that these services will evolve over the next two or three years. Because of that, network organizations should also work with the CSPs whose solutions they are evaluating to get a commitment about topics such as how soon after new functionality is available will it be part of the managed SD-WAN service?  Will there be additional charges for the new functionality? Network organizations should not expect to get detailed, specific commitments about future functionality, but they should expect to reach an agreement in principle for how new functionality will be deployed and priced.

Conclusions

Whether it is deployed on a DIY basis or as a managed service, the technical characteristics of an SD-WAN solution are a strong indicator of how successful that solution will be in the marketplace. When it comes to managed SD-WAN services, the more willing and able a CSP is to create the kind of relationship that makes network organizations feel good about adopting their SD-WAN services, the more successful that solution will be in the marketplace.

I strongly advise my clients to conduct a Proof-Of-Concept (POC) of any SD-WAN solution prior to agreeing to adopt the solution. As I mentioned in a previous post, conducting a rigorous POC enables a network organization to build a compelling business case for adopting an SD-WAN solution. Another outcome of conducting a rigorous POC is that it helps the network organization and the CSP build a positive relationship, because the results of a rigorous POC are a good indicator of how the SD-WAN solution will perform once it is broadly adopted. These results can also be used to craft an SLA for at least some of the functionality that is provided by the SD-WAN appliance.

About the author
Jim Metzler
Jim has a broad background in the IT industry. This includes serving as a software engineer, an engineering manager for high-speed data services for a major network service provider, a product manager for network hardware, a network manager at two Fortune 500 companies, and the principal of a consulting organization. In addition, Jim has created software tools for designing customer networks for a major network service provider and directed and performed market research at a major industry analyst firm. Jim’s current interests include both cloud networking and application and service delivery. Jim has a Ph.D. in Mathematics from Boston University.