Network technologies often seem to overlap, particularly where several somewhat-related ones end up going in the same physical place in the network. This may be a factor in something talked about in a recent SDxCentral piece, which speculates that SD-WAN is just a “Trojan Horse” for SASE, meaning Secure Access Service Edge. I think there is a relationship between the two, but it’s a lot more complicated. Maybe it’s even a case of parallel evolution.
Most everyone knows that SD-WAN is a technology that got its start because small sites, particularly in remote areas, were often unable to get on the corporate VPN because MPLS VPN connectivity wasn’t available to them, or was too expensive. SD-WAN creates a real or virtual overlay on the Internet that is then linked to the real corporate VPN, putting all the SD-WAN sites neatly on the VPN without MPLS.
SASE’s story is more complicated. There’s a good argument to be made (and the SDxCentral piece suggests it) that SASE was a product category seeking a problem to solve, until COVID came along. A good argument but not a great one, because there’s a kind of implicit First Law of Branch Networking, otherwise known as the Conservation of Boxes principle. It says that branch connectivity solutions will ultimately converge on the smallest number of devices needed to do the job, which is usually one device. Since branch offices have service termination, local network connections, and security, Conservation of Boxes says these have to be combined, hence the SASE. COVID was just a proof point.
That’s not where the complexity ends, either. SD-WAN is a demonstration of what might be called the First Corollary to that First Law, which says that a vendor will try to stuff all the useful functions possible into their box to maximize the business case. That is actually the driver behind Conservation of Boxes, because it creates the competitive drive toward simplification. So what we have here is a set of loose security and connectivity features in a branch, a new kid on the block in the form of SD-WAN, and the inevitable Conservation-of-Boxes drive toward optimality. SD-WAN can be expected to grow in features, and some of those features will be features that were already supported by other devices.
This has put larger network vendors in a tough position. On the one hand, they’ve made money by selling incremental box-based improvements to networking at the branch level. On the other, here’s this SD-WAN thing that threatens to puff out with features to become the god-box of branch networking, the SASE.
An integrated approach to connectivity is a general threat, saving perhaps to any firmly established incumbents. New issues offer vendors an opportunity to introduce themselves to buyers and inject their solutions into deals previously lost. Integrated strategies also favor incumbents because, as one enterprise CIO once told me, “If you’re putting all your eggs in one basket, make sure it’s a strong one!”
All this suggests that there is a relationship, one with both positive and negative elements, between SD-WAN and SASE. Does that make SD-WAN a Trojan Horse? If it does, how does that impact the risk/reward balance for vendors?
The Trojan Horse argument is based on two points. First, any new box or function will tend, as I’ve noted above, to grab onto associated features and functions to improve its own business case. That would mean that SD-WAN would naturally expand into other connection-point areas, and at some point would surely end up looking like SASE. Second, if SD-WAN actually brings any feature value to a related connection area, it naturally changes the market dynamic for that area. SD-WAN seems to have both these effects.
A good example is that SD-WAN implementations, because they separate traffic between virtual-VPN and Internet, often provide some form of prioritization control. That feature may be an element in an edge router value proposition. The same could be said for encryption, and of course if an SD-WAN implementation has zero-trust security features (which a very few do), then that could be perceived to compete with traditional barrier-based mechanisms like firewalls.
From this, it seems the argument that SD-WAN is a Trojan Horse (or perhaps a stalking horse) for SASE is valid. I don’t think so, because I think that the two have really been one thing all along. “Connection-point services”, the sum of stuff that a user would expect to see as a service feature provided at the network’s edge or demarcation point, are a group of features. You shouldn’t really be taking some combinations of features from that group and calling it a “product category”.
We all know that analyst firms can make more money by creating a new product category than by assigning new products to an existing category. Thus, it’s hardly surprising that we have categories springing up that are really simply rearrangements of others, or evolutions. I think that’s the case here, and we’re ignoring the big factor behind it all, which is virtual networking.
Virtual network technologies, including SD-WAN, are almost always technologies that overlay (in a real or logical way) the real network, and since they’re user services the process starts with the user’s point of connection. Any virtual network will therefore be first an on-ramp for the user and second a device that sits at the “real” network edge. If you define something that’s designed to be a “service edge” you’re defining something that’s going to sit there too. Edge devices tend to be driven by a single mission set. Thus, parallel evolution.
There’s also perhaps an element of coincidence in all of this. SASE, after all, names a place as much as it implies a security function. If you, like me, believe we’re evolving toward that ultimate level of service personalization called “network-as-a-service” or NaaS, then what’s really happening is that SD-WAN is becoming NaaS, and SASE is just another name for the place the device that’s at the edge of this new virtual network service happens to sit.
So will vendors and analyst firms eventually get this? Not likely; reality rarely overcomes opportunism these days. Vendors are very concerned about protecting their security revenue stream, a revenue stream that would (if we had full NaaS in place) suddenly disappear. If every user/application is a NaaS consumer, there’s effectively zero-trust security in place. Analysts will, instead of defining that which is and has always been happening, simply say that a “NaaS edge” is another product category. Business for all, then, continues as usual.