Here’s a simple (seemingly) question. If SASE is all about secure access to services, what services are we securely accessing? Is SASE, or NaaS, about a transformation of services, or a transformation of the on-ramp to existing services? Enterprises and network operators are both struggling with that question, according to my contacts with both groups, and vendors are struggling to position their stuff optimally, so apparently the market is struggling too.
Is this a question we can even answer, though? If I dig through enterprise comments on SASE, I find some interesting points that just might lead us to some useful conclusions; certainly some interesting ones.
Enterprises are roughly split between the view that SASE is really a security appliance and that it’s essentially built on SD-WAN. I think this split is behind the question I posed, or at least behind the fact that something that basic still is a question. Enterprises who see SASE as a security strategy see the “services” it provides access to as the services they’re already consuming. Enterprises who see SASE as an extension of SD-WAN are themselves split; about half believe that the services are SD-WAN services and the other half that there’s something beyond simple SD-WAN, like network-as-a-service (NaaS).
If you dig into how these belief sets developed, you find (not surprisingly) that they’re determined by the pattern of strategic influence of network equipment vendors. Enterprises who have a single dominant network equipment vendor tend to fall into the SASE-is-just-security camp, and I think this is because network vendors have a robust security business that they’re interested in protecting, even at the expense of kneecapping a new technology by limiting its scope. The enterprises who have set a multi-vendor policy fall more often into the SASE-is-SD-WAN camp, and this seems to be because they’ve adopted vendor and product selection strategies that assign more technology planning to the enterprise than to vendors.
Right now, I’d have to say that the SASE-is-security camp is winning, mostly because even vendors who might benefit in the long term from a more aggressive SASE positioning are either reluctant to push a strategy that might undermine security sales, or just aren’t pushing their own SD-WAN capabilities to the fullest extent possible.
Network equipment vendors have always been a bit skittish about any overlay-network technology. Most jumped into the SDN game when that was a hot area, and when changes in data center networking requirements (multi-tenancy for cloud providers and virtual-network requirements introduced by things like Kubernetes) demanded a more agile network model. Still, overlay networks threaten a tapping off of new requirements, new benefits, from the underlying IP infrastructure that’s the money machine for vendors. This second factor, additive to the desire to protect their security business, seems to be making all network vendors, even up-and-comings, less aggressive with the notion of SD-WAN and NaaS.
Operators have their own concerns about SASE, SD-WAN, and NaaS (beyond the risk of cannibalizing their VPN business), and all of them can be summarized in one term—opex. Well over two-thirds of operators who offer or plan to offer SD-WAN or NaaS services are more interested in doing it via a managed service provider (MSP) partnership than fielding their own offering. These kinds of services, you’ll note from my blog on December 6th, didn’t figure in the fall technology plans of any significant number of network operators.
If you add up all the views from the various stakeholders in the game, I think there’s a common thread here, which is SD-WAN versus NaaS. SD-WAN is seen as a glue-on extension to VPNs by pretty much everyone, even though there are a few enterprises who are looking seriously at shifting away from VPNs to SD-WAN. NaaS is viewed by enterprises as a new kind of service, but by both vendors and operators as a tweaking of existing services, usually via an SASE edge. None of these parties really has a firm view of just what kind of service NaaS really is, meaning what features it has and how it’s differentiated from SD-WAN and other existing services. That question, the question of NaaS, is really at the heart of not only SASE formulation, but perhaps of the future of networks.
As I blogged yesterday, Amazon’s AWS Cloud WAN may be the first salvo in the NaaS wars. In effect, what it does is to virtualize some or all of an enterprise network, and create what might be a unification of SD-WAN, VPN, and virtual-network NaaS, which not only would necessarily define NaaS, but also its on-ramps and points of integration with existing services, meaning how you evolve to it. It would also likely define SASE, but the big news would be that it could define how higher-level services like Amazon’s own cloud and (possibly forthcoming) edge services and AWS web service features become part of SASE integration.
I don’t think there’s much question that cloud providers like Amazon would like to generalize the concept of SASE to make them a gateway to their cloud services. Expanding on AWS Cloud WAN would surely do that, but it also stakes out a possible claim to VPN services offerings by cloud providers, something that could be a direct attack on the network operators. Operators are motivated less by opportunity than by competition, which is one reason why their technology plans seem pedestrian. Would cloud provider threats induce operators to be more proactive with new services? Maybe.
The reason for the qualification is that, as I noted on December 6th, operators are still more dependent than they like to admit on vendors taking the lead in technology shifts. Vendors, as I’ve noted, have been quick to claim SASE support but unconvincing with respect to their support of anything really different in a service sense. Further, network vendors don’t have a role in higher-layer services like cloud web services, which means that they might well see a service-centric expansion of SASE as something that could admit cloud software players like HPE, IBM/Red Hat, or VMware onto the SASE leader board.
Is NaaS just network services, or is it also higher-level and even cloud services? The final determinant in this question may be the ever-present-in-ink but still-unrealized edge model. One of the most important changes that a cloud-provider vision of SASE might bring is a specific link to edge services. If Amazon could assert web service APIs from its cloud across SASE to an enterprise, might they also assert edge-service APIs, which would require they formalize the PaaS edge model? SASE could truly unify “hosting” and “services”, and also define how they’re related.
The obvious question is what NaaS and SASE would define as “services” and what those exposed APIs would look like, particularly for edge computing. Tomorrow I’ll discuss how IoT and metaverse might unite to create something new and powerful, and even a bit of what that might look like.