Analyzing Cisco’s View of NaaS

Cisco released a report on network-as-a-service (NaaS) that’s eye-opening in some ways and utterly predictable in others. On the one hand, it’s easy to see what users are hoping NaaS will do for them, and the range of their hopes is broader than I’d thought. On the other hand, the report shows a remarkable consistency with past surveys by proving that most people who responded were just winging it.

I’ve noted in several past blogs that users tended to respond to surveys in a way that made them look good, rather than by relating what they really did or even knew to be true. On the average, I’ve found that at least a third of users who respond to surveys don’t relate reality, and in this case Cisco found that 36% of their respondents said they already had NaaS when likely the number who met Cisco’s definition was in the statistical noise level. More on this later.

Cisco sees NaaS as “a cloud-enabled, usage-based consumption model that allows users to acquire and orchestrate network capabilities without owning, building, or maintaining their own infrastructure.” Cisco said they believed that many users who simply had a managed service provider (MSP) believed they were NaaS users, which would make NaaS more a retail packaging factor than a technology. I think it likely goes further than that, and we’ll have to keep that in mind when we look at some of the specific things Cisco’s survey found. I won’t include them all, just those that directly relate to the question of what a NaaS really is.

The first point in Cisco’s results is that “IT teams recognize the top NaaS benefit as freeing up IT teams to deliver innovation and business value (46%). Another 40% recognize NaaS as improving response to disruptions and 34% as improving network agility.” Obviously multiple responses were allowed here, but I think that the responses show that IT personnel (presumably CIO-level and direct reports) believe that the cloud as-a-service model succeeded in breaking the dependency on owned, fixed, infrastructure for computing. They now want to apply that same model to networking.

To me, this says that what users want from NaaS could in fact be delivered by any service that was usage-priced, resilient, and scalable. You could fit that pricing model to an IP VPN, for example, and they’d be happy. The cloud, then, is less a technical requirement for a NaaS implementation than it is the way that computing technology broke the infrastructure dependency for computing.

The next critical point is “The top services required from NaaS providers are network lifecycle management (48%), network resiliency (42%), and monitoring and troubleshooting to meet SLAs (38%). This again seems to be a translation of cloud features into the NaaS space, suggesting that users are seeing cloud computing as the go-to as-a-service framework and expecting what they want from it to be available for NaaS too.

The interesting thing here is that none of the responses talks about new features of NaaS. There’s nothing about NaaS as a per-user, per-application, sort of service, what I’ve suggested is connectivity as a service. There are no new security features cited, either. Again, these requirements could be met without making real technical changes to existing VPN services.

Some security issues are raised in the next point: “Concerns range from whether NaaS can support unseen emerging demands (30%) to loss of security control (26%). The cost and disruption of transitioning also ranks high (28%).” Note that there’s less unanimity on concerns than on benefits and expectations. The first of the concerns shows a continued presumption of a static service model for networks (can the cloud support unseen emerging demands? Sure.) Disruption and transitioning costs, the next-biggest concern, seems to suggest that users fear change more than a lack of specific new service features. Security issues are on the bottom, and my own surveys have shown that users will always say they believe there are management problems or security problems if they need to cite things about a new technology that they find worrisome.

The next point says that 75% of users agree that NaaS will give IT teams and professionals opportunity to advance their skill set, but a quarter of users indicated they’d trust an integrator rather than their own staff to put NaaS in place. This seems a bit of a contradiction on the face, but there’s a deeper contradiction too.

It seems to me that the high rate of response on this point indicates it was suggested (“Do you think NaaS will help IT teams advance….”) rather than a spontaneous comment. It also seems to contradict the assumption of prior points, which was that the biggest goal of NaaS was to reduce adoption/transformation burden. Finally, isn’t the sense of earlier goal comments that NaaS was supposed to mean less stuff to own and manage? What is an integrator even doing in that situation?

The final point I want to highlight is the view that NaaS was most likely to be adopted during an upgrade cycle, and that SASE and multi-cloud were likely to be entry points to NaaS. There’s little question that every major change to networks or IT infrastructure would be timed to the point where current assets were largely written down; the cost of the write-down would have to be borne by the project. And since SASE is a “service edge”, it follows it’s a NaaS edge. There’s not much insight conveyed here, in other words.

Now, I want to contribute the results of my own enterprise conversations on NaaS, but to do so I need to return briefly to the point I made earlier about surveys. The most important single truth about surveys is that they produce results when the people surveyed are actually involved with the question being surveyed. If you want to understand what issues currently face network operations, you talk to an operations person. If you want to understand how an enterprise would see its service needs evolving, you talk to a network planner or even an application planner. It shouldn’t be a surprise to any of you who read my blog that I’m a futurist, a strategy consultant. I talk to the latter group, the planners. Vendors usually survey the former, and that results in a difference in perspective.

Planners tell me that they hope NaaS will be an almost-personal thing. You, as a user of the network to reach information and applications, have specific connectivity needs. You want them satisfied, and from your perspective there’s nothing that’s really aiming at that. Planners, hearing from their users, see the possibility for communications that supports the information relationships each user needs, as a service delivered to that user. To these planners, the user gets an IP address and has the ability to decode URLs, and that’s the extent to which they want to interact with the network. Everything else is set up by policy.

In this mode, “secure access service edge” or SASE is a logical gateway to NaaS, but it’s important to understand that having an SASE doesn’t imply that you have NaaS, or even that you could support it. NaaS is a network relationship with the user, like any as-a-service model. To distinguish NaaS from a simple VPN, you have to accept that it goes beyond site networking (which is what a VPN provides) and into user-specific connectivity. Cisco’s paper doesn’t address this, likely because it’s a survey of network people and not of network planners/users.