Will this, as an SDxCentral article suggests, be the year of NaaS? I think somebody has suggested that every year for the last five years or so was going to be just that, so it might be interesting to look at why we’ve not achieved NaaS so far, starting with an inability to define what it is or what its value proposition might be. NaaS, of course, stands for “network as a service”, and one thing the article does is outline an actual driver for the concept, a driver that takes a step toward developing a definition. It also ends up introducing a question, which is whether NaaS has already snuck up on us, from an unexpected direction.
One of the problems with NaaS is that most network services are as-a-service models already. Look at MPLS VPNs, which frame what used to be private networks built from digital trunks and routers into a service that replaces all that interior plumbing. The article notes that “NaaS replaces legacy network architecture like hardware-based VPNs and MPLS connections or on-premises networking appliances like firewalls and load balancers. Enterprises use NaaS to operate and control a network without needing to purchase, own, or maintain network infrastructure.” That could be interpreted two ways. First, NaaS extends the VPN concept to network-related on-prem technologies like firewalls and load balancers, so it’s more comprehensive. Second, NaaS allows users to expense their networks rather than build them with capital equipment.
Companies like Cisco tried to offer that second option by “selling” equipment via an expensed service, so the architecture of the network didn’t really change but the way it was paid for did. Some companies like this approach, but it’s not been a stirring success, and it’s not accepted as NaaS by the majority of enterprises. Thus, it’s the first NaaS interpretation that seems to matter.
The reason for that is the increased mobility of workers. Work-from-home during the lockdown not only created an almost-instant need to empower people who were in places that fixed network connections didn’t serve, but also convinced many workers of the lifestyle benefits of out-of-office work. That meant that somehow these workers had to be connected effectively and securely. And since mobile workers are mobile, the mechanisms of NaaS would have to be agile enough to respond to changes in worker location. Arguably, they should also be elastic in terms of capacity and other SLA attributes too.
The basic notion of NaaS as presented in the article is that NaaS would absorb into the network the edge elements that today are on-premises. If you think about this model, it’s hard not to see it as either an implementation of an old idea or the target of a new technology that’s not really considered network technology at all.
The old idea is network functions virtualization, NFV. If you’re going to eliminate on-prem capital equipment it makes zero sense to install the same gear in an operator location; you’d have to charge more for NaaS if you couldn’t deliver any technology efficiencies to cover operator profit margins. Thus, the assumption is that you would host virtual forms of those previously premises devices, which is what NFV was all about.
The interesting thing, though, is that since its inception in 2012, NFV has evolved toward the “universal CPE” or uCPE model, which relied on a premises device to serve as a kind of agile hosting point for service features. This doesn’t address the problem of mobile workers, but uCPE isn’t mandatory for NFV, just a focus of convenience. The question is whether NFV is really the right approach to NaaS, given that it’s not exactly swept the market over the last decade.
That’s particularly true when you consider that new technology I mentioned, which is the cloud.
Companies have been adopting cloud computing to create “portals” for prospects and customers, front-end elements to their legacy applications. Since prospects and customers can hardly be expected to install specialized hardware on their premises, and since companies are unlikely to pay to do that for them, this portal model demands that the business network ride on a universally available service, the Internet, and that the cloud provide things like security and even VPN access. During the lockdown-and-WFH period, companies started to play with the idea of using the same strategy for worker access.
Cloud tools like SASE and SSE are examples of the absorption of network features into the cloud. The fact is that we’ve been developing what the article defines as NaaS as an element of cloud hosting. Public cloud providers are, in effect, doing the absorbing of those additional on-prem devices, and as I’ve noted in other blogs, the “cloud network” is increasingly a full implementation of NaaS.
So what we seem to have here is a realization of NaaS that’s not due this year, but has already happened. If you look at the pace of cloud adoption of network security and VPN features, we could argue that 2022 was actually the “Year of NaaS”.
This raises the question of whether we’re seeing perhaps the ultimate form of “disintermediation”, where network operators find themselves excluded from a potentially profitable service set. Through 2022, almost three-quarters of operators told me they believed NaaS was a logical extension of their current service set that could raise revenues. I think they were correct, but I also think that operators sat on the sidelines as the NaaS concept was implemented downward from the application side.
Ultimately, networks connect stuff, they don’t create stuff, and it’s the “stuff” that businesses and people want. With the advent of the Internet, we saw a fundamental shift in the mission of networks. In the past, it facilitated connection, presuming that what it connected took care of the “stuff”. When the Internet came along, it bundled connection and experience, network and “stuff”. The cloud built on that. But operators didn’t recognize the importance of the Internet transformation, other than to bemoan its “disintermediating” operators from higher-value services. All the factors that could have driven us to “smart” networks if operators had recognized conditions, drove us instead to consign advanced network features to that “stuff” category, a category operators had already lost.
The cloud is an external-to-the-network resource. The Internet represents universal connectivity. Combine the two, which has already happened, and you get what’s arguably the most logical, efficient, and ubiquitous platform for delivering NaaS. This means that operators disintermediated themselves, and failed to realize a fundamental truth about the supply-side, build-it-and-they-will-come nature of telco planning. You have to build it, or they will come to someone who does.