After my blog on the cloud or Internet absorbing the WAN, I got a lot of comments from enterprises. Sixty were particularly detailed and even included some back-and-forth clarifications, and all were thoughtful enough to warrant some discussion. Networking is changing, and the majority of enterprises think it will change radically in the next five or ten years. The question is “To what?” Let’s see what we can do to find some answers.
It turns out that when you talk to enterprises about network evolution, you get answers in three dimensions. One is the “provider” dimension, which reflects how they see their relationship with operators and vendors evolving. A second is the “technology” dimension, meaning that specific network protocol/technology is used. Last is the “service” dimension, which means not so much whether they use VPNs or SD-WAN, but the nature of the services and their relationship to their applications. I want to start with the last of the three, because it was in this area that I got the most profound comments.
When I first got involved in enterprise networking, companies networked locations, and they did that by combining digital data pathways (in the US, DDS 56 kbps, T1 1.544 Mbps, and limited T3/DS3 at 45 Mbps) and their own nodes. A private network was literally that, a kind of mini-form of a public data network. Almost all enterprises have largely maintained this site-centric view since.
What changed things was first the growing number of “road warriors” or “unplugged” workers, and then the work-from-home shift created by COVID. This gradually shifted thinking from site networks to people networks. Connectivity at the enterprise level was the sum of the connectivity at the worker level, which meant that this shift established a two-tier model, a “virtual site” that could move around, and that therefore had to be connected via multiple tier-two access options.
A slight majority of enterprises who commented said that there was already a clear third tier, which was “application networks”. This creates what’s essentially a new tier, making a worker network into the sum of application networks. Workers’ roles determine the set of applications they access, and in this model, prospects, customers, partners, and other relationships outside the company are also roles, each with its own set of applications. Further, since the way in which applications are accessed, and in particular timing of access, varies, the collective impact of the variation sets the instantaneous requirements for worker-centric or site-centric planning. Workers sort of drag their collective application networks with them as they move, and if they collect often at a specific place (their office), then that sets site-network planning foundations.
This model, say the key 60 in my chats, is what’s really driving the evolution of services, and it’s this evolution that’s going to transform enterprise networking. Some (38 of the 60) say that this is where the real push for network-as-a-service (NaaS) comes from. As the service model, at this highest level, shifts from site to application, network connectivity depends on the juxtaposition of two “wheres”, where is the user and where is the application hosted. This group of 38 also notes that this inherently favors the “Internet” model of connectivity over the MPLS VPN or digital-trunk-and-node models.
All enterprises agree that site networking and an Internet model may not be universal. The reason is that there are “people” sites and “facility” sites, distinguished by whether the network services are delivered to people in a location or to facilities like ATMs or IoT systems. In the latter case, the more facility consumption there is, the more static the source/destination connectivity requirements are, the easier it is to satisfy them with a fixed-site connection. That’s particularly true if the QoS requirements are stringent, which I’ll get to below.
For variability, you can’t beat the Internet. The Internet is, at the network level, a vast pool of connectivity that users and applications can draw on as needed, through an access connection that’s established where the user and the resources are located. This means the Internet is a connectivity resource pool, and that NaaS fits the notion of the Internet model quite well, at least at one level.
The 38 enterprises say that the true version of NaaS can only emerge from the Internet, because application/role networking demands universal connectivity. They say there are two NaaS models, the “implicit” and “explicit” models, and that the difference between the two is in the nature of the connectivity—best efforts or “assured”. Those with cloud experience will recognize this as being similar to the various “elastic” versus “dedicated” types of hosting, but of course there are such options in the cloud and not at this point on the Internet. The Internet financial model may thus be a major factor in how future enterprise network services evolve.
The combination of SD-WAN and SASE cloud services are, according to most enterprises, sufficient to ensure that the majority of business traffic will migrate to the Internet in the next five to ten years. The Internet already offers the best connection economy of scale of any network service, but it has its issues, and enterprises agree that these are largely responsible for the delay in having a fully Internet-centric connectivity future.
The primary issue with the Internet is security. The Internet is seen by all enterprises as the greatest source of security threats, surpassing all others combined. The threats can be active intrusions to steal or contaminate information, or passive denials of service that simply interfere with operations. The problem is seen as acute for “facility” or IoT/M2M connectivity and financial terminals. These fixed/static missions for connectivity are generally seen as easier to secure from intrusion/hacking, but still subject to DDoS.
The second issue is QoS/QoE. The Internet is best-efforts, and net neutrality policies (which are themselves so variable nobody wants to bet on them) can extend to bar services that offer premium handling, and in theory at least discourage any services that are purely usage priced, because usage pricing is tolerated by enterprises for premium handling only.
My view here is a bit more optimistic (or pessimistic, depending on your perspective) than that of enterprises. There is nothing but cost pressure on networking and IT these days, and unless it’s lifted by a revolution in applications and business cases, I think that software and network vendors will be driven to adapt to the limitations of today’s Internet services, and that ISPs will be driven to work to address the issues that inhibit migration of enterprise traffic. I’m convinced that ten years is far longer than an Internet transformation will require, and that there’s a better-than-even chance that even five years will prove longer than needed.
As far as NaaS goes, I think that the model that we tend to think of, which would roughly correspond to compute as-a-service models, is unlikely to develop unless we assume some form of Internet QoS. Enterprises reject pure usage pricing, and if Internet economies draw away traditional traffic that tolerates best-effort handling, it will be very difficult to make any assured-service alternatives cheap enough to be attractive.
The interesting thing is that SD-WAN may actually offer the best framework to use for NaaS. Some implementations (Juniper’s Session-Smart Routing, acquired with 128 Technology is the best example) already provide per-application-session traffic recognition and prioritization, and an operator could in theory use it to steer traffic into QoS-specific tunnels. However, I’ve not heard much signs of converging interest in NaaS from either enterprises or operators. Enterprises like it if it’s cheaper, and operators if it gains them revenue.
So have events overtaken NaaS? That was my thought at first, as some of the comments came in, but now as I’ve reflected on them all, I’m not so sure NaaS ever had a real chance. Five years ago, perhaps, you might have had a transient opportunity to present a VPN version of NaaS, but I don’t think it would have paid back for the simple reason that enterprises wanted cheap connectivity even then. Operators pushed NaaS as a revenue source, but enterprise comments say it never was that because low cost always wins in the end. That means NaaS may have, probably was, doomed to lose from the first. Applications that needed premium handling would have been redesigned to work with standard handling, and that’s the lesson of 2025. Remember it well, operators.
