I’m not surprised that the SD-WAN space is shifting, but I’m a bit surprised at how fast the shift is happening. I’m very surprised that the implications of the shift are being missed by so many, including most of the SD-WAN vendors themselves. The force most likely to bring a focus to the market is simple—competition.
In a number of SD-WAN pieces I’ve written (as blogs, tutorials, and guest blogs for others), I’ve noted that the fastest-growing channel for SD-WAN delivery was the network operators themselves. A recent study done by Vertical Systems for the MEF and quoted in Fierce Telecom says that a majority of US telcos already offer SD-WAN service. While the study claim that this is conforming to the MEF’s Lifecycle Service Orchestration (LS) is optimistic at best and specious at worst, the rough numbers align with my own findings. The most significant point is that fewer than one operator in five isn’t at least planning the new service model.
Another story on SD-WAN, this one focusing on the cloud provider commitment to the concept, is also running in Fierce Telecom. This one, based on IHS Markit research, also has some issues; there is a big difference between a cloud provider “jumping into” SD-WAN and a cloud provider supporting SD-WAN. However, I’m told by some cloud provider contacts that at least two of the three public cloud providers are seriously looking at offering SD-WAN services in some form (Amazon and Microsoft).
If the network operators themselves commit to SD-WAN, even if they continue to sell MPLS VPNs as a site connection option for larger sites, smaller MSPs would suffer considerably from the competition. If public cloud providers got into the space, the smaller MSPs would have little hope and even network operators would face some pressure. How much and how fast will depend on the impact of the SD-WAN service competition on SD-WAN features.
SD-WAN is one of several examples of a “virtual network” or “network-as-a-service” model. All these kinds of services are based on the simple principle that a network service is defined by its customer interface. That’s a form of the “black-box” or “intent model” abstraction approach to networking I’ve been blogging about for a long time. What you sell is what your buyer sees; how you produce it is so much uninteresting garbage to the buyer unless it impacts what’s seen looking into that customer interface.
If we assume that the service interface is the native language of the network that asserts it, then the virtualization effect of SD-WAN is minimum. The corollary is that the value of SD-WAN to the service provider depends on how different the service is from the network. The magnitude of the difference is a function of whether SD-WAN advances features beyond the natural feature set of the network, and whether the network changes over time to a technology model that doesn’t depend on the same features that originally defined the service.
Google’s Andromeda core concept of SDN is a good example of the latter. You can make an SDN network “look” like a BGP autonomous system if you can emulate the BGP interface where the connections from the outside are made. SDN doesn’t know or care about BGP, but for all practical purposes it can form a BGP core equivalent to that of a super-router network if it emulates the edge interface. SD-WAN technology does this by emulating an MPLS VPN interface over what’s essentially a tunnel over the Internet.
It’s fair to wonder whether operators today are sensing their evolution to things like SDN (or to the MEF’s “Third Network” concept, if you like) and see SD-WAN as a service envelope they can wrap their transformation in. There’s a limited truth to that; virtually every operator has some champions of this protected-evolution approach. The broader reason for operator interest is more pedestrian—money. MPLS VPNs are not going to support every business site, and in fact as consumer broadband capabilities advance, it’s more likely that every branch site will end up moving to SD-WAN over time. MPLS is not a growth market; it’s probably doomed in the end. For operators, then, to surrender SD-WAN and that end-game to competitors, and ride MPLS into the ground, is hardly smart.
This sets up the way SD-WAN vendors shake out in the present. People like Cisco buy SD-WAN technology to emplace it in edge routers so as to make it possible for them to play a role in a future when MPLS terminations are going to decline. However, Cisco makes more on MPLS users than on SD-WAN users, in part because the MPLS VPN space lets them sell IP routers to carriers too. They don’t want to promote a shift to SDN (imagine Cisco selling Google-like BGP-SD-WAN to empower SDN as a replacement to big routers!) but they want to sell something if/when one occurs. Defensive applications of SD-WAN then dominate. Thus, leading SD-WAN solutions are solutions that stick the SD-WAN finger in the transformation dike rather than rebuilding things on a sound basis.
The problem with this approach is that you can’t win a defensive war, only influence the pace at which you lose it. Suppose operators all adopt SD-WAN, and can now sell VPN services globally, even outside their own infrastructure footprint. Don’t the operators then pose the same risk to each other as the SD-WAN vendors or MSPs did? How do the operators then respond? They could lower their price, resulting in an operator-driven price war that makes VPN services less profitable overall. Bad idea. They could compete by offering better features, too, and that seems to be a much better idea.
SD-WAN feature competition would mean that an operator with a superior feature set could then hold off other operators from poaching their small sites. SD-WAN features could also be the thing that empowers current MSPs to hold their own against operators who elect to stay with nothing more than basic SD-WAN connectivity. The feature advantage is greatest for early movers in the feature space, of course, and for operators who select SD-WAN technology that has the greatest potential to add new services/features to basic VPN connectivity.
One fairly common feature extension for SD-WAN VPNs today is the ability to host a software element in the cloud to provide VPN connectivity there. It’s often impractical and sometimes impossible to connect cloud applications to a traditional MPLS VPN, but most of the SD-WAN technology today can support cloud-hosted SD-WAN node. VMware, who has specific aspirations to offer hybrid cloud hosting on the premises side, needs to offer SD-WAN connectivity I the cloud to achieve that goal, which they do. That a cloud provider like Amazon or Microsoft supports the VMware goal (which they do) doesn’t mean that either provider intends to sell SD-WAN services.
They could, however. Cloud providers have at least as firm a fixation on hybrid clouds as vendors like VMware do, and in fact hybrid cloud is (as I’ve said in prior blogs) the battleground for additional cloud revenue and market share in the near future. The problem with accepting vendor (network or IT) support to reach that goal is that everyone won’t use the vendor you work with. There’s also the challenge of deeply integrating any SD-WAN node client with related cloud offerings, particularly in the areas of mobile app support and IoT/event applications.
Think of the services that a cloud provider could integrate with SD-WAN (or, in fact, that SD-WAN vendors could offer by providing API links to those cloud services). These services and features would threaten network operators’ SD-WAN opportunity and their MPLS VPN opportunity at the same time. It would threaten operators with being disintermediated from the whole of business networking, making that an OTT application.
Do operators have anything left in their own arsenal to combat cloud provider SD-WAN? One possibility goes back to my early comment on the service interface being the window on the revenue world. SD-WAN today is still an IP/VPN service interface, and there are plenty of legacy services that don’t expect that interface. In industries where technology write-downs are slow (utilities, government, some healthcare, some financial), there’s stuff out there that can’t be connected to SDN, to Ethernet, even to packet networks. Could somebody create an abstraction of legacy service broad enough to embrace all these options? The operators, being players with their own share of slow write-downs, might be just the thing.
This is what’s at stake here. Operators have been whining about disintermediation for decades, but if they fail to see both the need for feature differentiation in SD-WAN and the likelihood that cloud providers will embrace it, they deserve what happens. MSPs who ignore the feature lesson are likely to add themselves to the whining chorus in 2019. Changes are coming, for sure.
