One of the tech topics that seems hardest to track is “network-as-a-service” or NaaS. Like a lot of technologies, NaaS is subject to what we could kindly call “opportunistic redefinition”, meaning NaaS-washing. When that happens, definitions tend to get fuzzy because vendors broaden the definitions to ride the media wave. I wondered whether we might address this problem by starting from the other end, the demand or buyer side, so I’ve culled through six months of enterprise data on NaaS, and here’s what I found.
If we had to pick a NaaS definition or service model from the stories and vendor offerings, we’d likely pick “usage pricing” as that model. That’s not an unreasonable definition either, given that in cloud computing, the “as-a-service” model is often based on usage pricing. The first question we’d have to ask about NaaS is therefore whether a usage-priced service model is actually appealing to the market, meaning whether it supports a symbiotic buyer/seller paradigm.
Enterprises listed “cost savings” as their absolute number one benefit objective for NaaS. Nothing else even comes close, in fact. Of 112 enterprises in my analysis, every one put it at the top of the list. The presumption is that by offering network-as-a-service, an enterprise could lower costs by reducing average capacity needs, since NaaS would adapt to peak periods. Very logical.
The challenge is that if you ask service providers, 18 out of 19 who admitted they were “considering” a NaaS offering, said that their primary goal was to generate new service revenue. Let’s parse that combo. Here’s the buyer, who wants NaaS because it lowers his cost, and here’s the seller who offers NaaS so the buyer will spend more. If a chatbot offered that dazzling insight, we’d say it made a mistake.
The fact is that there are very few service features that a buyer would spend more on. Security, cited as the number two benefit of NaaS by 97 of the 112 enterprises, was the only example enterprises offered as a justification for a higher cost for NaaS capability, and only if NaaS security let them reduce other security spending by more than the NaaS service would increase their service spending. This shouldn’t be a surprise; enterprises have a fixed business case for network services, and so there’s no incentive to increase spending if you can’t increase the business case. There are few “new” network projects these days, so there’s little chance of a major new benefit coming along to justify a new cost.
What about security, then? The “benefit” enterprises think NaaS could bring is the benefit of traffic, user, and application compartmentalization, meaning a form of connection control. While this is the most-cited security benefit, it’s cited by only 43 of the enterprises. The majority don’t have a specific NaaS feature they think would enhance security, and that they believe could then result in lower security spending elsewhere. For that group, I think a NaaS security benefit could be realized only if the service provider could establish a credible NaaS feature connection. For the group of enterprises who think NaaS connection control could enhance security, there are still issues that would have to be addressed.
First and foremost, connection control benefits from NaaS derive mostly from virtual networking as a likely NaaS foundation. I think that virtual networking is indeed likely to be the foundation of a credible NaaS, but you can do virtual networking without usage pricing, which is still a feature most think is the primary feature of NaaS. We could tap off the security argument for NaaS simply by using SD-WAN and/or broader virtual-network features.
Not all SD-WAN implementations offer connection control, because not all are aware of user-to-application sessions and capable of deciding what’s allowed and what isn’t through policy management. Of over 40 offerings in SD-WAN, only about five have any features in that area. Of my 112 enterprises, only 32 could identify even one of those, which means that the connection control features of SD-WAN aren’t widely recognized. Going to the broader virtual-network space, 88 enterprises could identify an actual provider of virtual networks (VMware’s NSX is the most-recognized) but only 15 could identify any other option, and only 9 said they used virtual networks for connection control and segmentation outside the data center.
A general virtual-network technology, which is available from VMware but also from network vendors like Cisco, Juniper, and Nokia, is capable of what’s needed for security-driven connection control, but hardly anyone knows. SD-WAN is generally not capable of doing that, but few enterprises know specific implementations that can offer it. One thing this argues for, IMHO, is a unification of the virtual-network space, a combining of SD-WAN and broader (often data-center-multi-tenant-centric) virtual network models.
My enterprise contacts weren’t spontaneously committed to a model like that. Of the group of enterprises who saw connection control and virtual networks as linked (9 in the real virtual network group and another 8 in the SD-WAN group, for a total of 17), they saw virtual networks creating closed application or user-role communities to which both workers and applications/databases could be assigned. That’s at least close to the model Juniper supports with the SD-WAN stuff it acquired with 128 Technology.
That would then raise the question of whether such a super-virtual-network model is the real service opportunity, and thus whether “NaaS” has any incremental value. I think it does, or could, if we take a different slant on what “as-a-service” means. Rather than linking it with usage pricing, look at it as connectivity as a service. That would mean that the connection model would be more dynamic than would typically be the case with a virtual-network strategy alone.
Dynamic connection management could mean a lot of things, and be implemented in a lot of ways. You could envision “communities” to which both users and applications could bind, but rather than the binding being largely static, it might be controlled by policies set at the community level, and might even allow users with certain credentials to join and leave communities at will. You could envision policies that would even look at the membership, and expel people or applications if certain users/applications joined. You could even envision a community policy to disconnect everyone, in situations like a security problem.
The interesting thing is that while users would be looking for usage pricing of services to be useful only if it saves them money, all of my enterprises thought that this NaaS model would be useful in security and that they’d pay for it if it at least contained overall security costs. More than half would accept a higher cost including security, if security were “significantly” enhanced. Thus, dodging the usage pricing issue might actually give network operators a path to revenue growth out of NaaS. But this would mean some serious work marketing features, something operators are notoriously bad at. Perhaps it’s time for them to learn to do it better.