Is networking heading into a software-first period? Should it be? There are areas on this topic where enterprises and operators agree, areas where those two groups disagree, and areas where there’s more or less agreement within each group. Is there any conclusions to be had from this disorder? Let’s see.
Let’s start with some numbers. I had comments on a software focus in networks from 229 enterprises and 72 operators. Of that group, 178 and 68, respectively, said that they believed software was of increased importance to their network infrastructure planning. Both groups cited largely the same drivers for the trend too; open-model networking, increased focus on operations, cost of equipment, and lengthening of period of expected useful life. The groups didn’t place the factors at the same level of importance, and enterprises showed more variability in their ranking of the factors than operators did.
The operators seemed to divide almost equally between a capex-focused camp (35) and an opex-focused camp (33). The first camp listed equipment cost and open-model networking as their top two priorities, and the second listed increased operations focus and lengthening period of useful life as their top two. The comments of both camps were particularly interesting.
The capex camp of operators were primarily retail ISPs, but also included some mobile operators still facing 5G RAN modernization. This camp was the one willing to accept open-model networking, but their preference was still to knock down the price of network hardware, hopefully from their current major vendor but if not, from a main competitor. The 5G operators in this camp had more interest in open-model networking than retail ISPs did, by far.
The opex camp of operators is made up of most of the larger, mature, ISPs and mobile operators. They are not, at this time, facing major new buildouts and in fact are hoping to avoid them. They are more focused on extending the life of current gear and raising profits by cutting costs, especially opex but also capex, but they see an open-model transition as being likely to cost them more on the operations side than it might save on the capital side.
Operators are often reluctant to classify themselves firmly into any single camp, mostly because the great majority are trying to cut costs anywhere they can. For most, the 5G budget period has come and gone, and the fact that 5G isn’t likely to raise revenues has become clear to the financial markets, making costs the exclusive focus. But even those with some 5G buildout still budgeted, the decline in 5G revenue credibility is impacting how the money will be spent, and how much pressure there will be to turn some funds back. In 2020, only one operator in eight said they saw such pressure; in the last six month one in three said they faced it.
5G did contribute something important to operator infrastructure planning, the notion that “open-model” can easily be turned into a synonym for “single-vendor”. While many (perhaps even most) operators and vendors believe that it’s easier to adopt open-model networks in a greenfield environment, in practice most say that they’re electing to focus on one vendor during deployment and “open up” down the line—perhaps. For sure, the open model assures them of way out of their single vendor if it becomes necessary, but they hope it won’t.
This attitude is most prevalent in the access network; as you get deeper (metro and core) all operators are more interested in and willing to exploit open technology. In part, I think, that comes back to our question about software-centricity. Most management focus is applied close to where services are delivered not deep where they’re invisible. In addition, management practices and tools can be less consistent where there are fewer pieces of gear. You can see that this doesn’t add up to much software drive for the capex camp.
On the opex side of the camp structure, there’s a diversity problem, in three dimensions. First, network infrastructure is almost always made up of multiple equipment types. Second, it often includes multiple vendors. Third, management needs vary from equipment-centric FCAPS to service and customer experience management.
The ONAP mission was to resolve all of this, but ONAP started off with fatal architectural flaws that my own (yes, extensive) experience with network operations says can never be corrected once put into place. Of the 88 operators I’ve engaged with, 57 say they are totally opposed to ONAP, 20 say they view it negatively, 8 say they have no view, and three said they have either adopted it or are trying it. Interestingly, ONAP was launched as an operator initiative, and its architectural flaws can be attributed IMHO to lack of software architecture experience among operators themselves.
What this all means is that for network operators, software is an important focus that so far is almost entirely unfocused. The Nephio project, whose goal is to apply Kubernetes to both network equipment (the NFV ISG’s physical network functions) and virtual network functions, hasn’t corrected all the problems of ONAP and doesn’t address everything in management and operations. Nothing else has really emerged. There is a lot of interest among operators in software, and some actual commitment to having software take a larger role in infrastructure planning, but operators want vendors to lead in transformation, and that’s not yet happening.
On the enterprise side, it’s much harder to even define camps, but if we need to try (the effort could be at least helpful) we could divide our 408 enterprises who offered comments into three—the data-center-centric group of 178, the cloud-centric group of 87, and the VPN-centric group of 143. The division here is based on what is exerting the most planning influence. In software terms, all three camps rate management of QoE at the top of their lists, but they expect to go about it in three different ways.
Companies with a data-center-centric perspective on networking were the rule up to a decade ago or so, and even now are the largest group. They have a fairly static set of remote offices that they connect overwhelmingly through MPLS VPN services, and their use of the cloud is still limited for their own workforce. Most of their network budget is associated with their data center LAN, and it’s driven mostly by application growth, containerization, or both.
This is the group most likely to embrace open-model networking meaning white-box switching, but their QoE focus is really more likely to be on Kubernetes and on a virtual-network plugin for it. In a LAN, the realistic goal is and should be to bury issues in capacity and connectivity. However, open-model is still a minority strategy; they want to stay the course with their dominant vendor. Even their VPN plugin is somewhat likely to come from that vendor, though VMware’s NSX is more popular.
The cloud-centric enterprises are highly focused on supporting applications aimed outside the company, on using the cloud to support their own workforce, or both. With the Internet and the cloud providing the “access network”, this group is migrating slowly (by default, usually) to a cloud-as-a-network model, which means that they really don’t worry about network software except as a cloud-resident SD-WAN component or SASE. Most of their QoE control is exercised via cloud management.
The final group, the VPN-centric ones, are perhaps the most interesting. One reason is that they are under a diverse set of pressures for change. You’re VPN-centric in part because your data center isn’t evolving quickly, which might be an indication that you are doing more in the cloud. You’re also likely to be more dynamic in terms of remote locations, which could also lead you to the cloud, or to an SD-WAN transformation.
VPN-centric enterprises, not surprisingly, are the group most interested in software to monitor and manage the user experience. In part, that’s because the VPNs have an SLA and so there are contractual guarantees that could be enforced to assure QoE. SLA monitoring for enforcement has a long history, and also a history of forcing (or encouraging, if you prefer) operators to monitor their SLAs from the supply side.
Where does this lead us with regard to software-centricity? To two different places, I think. For enterprises, software will surely drive network decisions more, but not network software per se. All the enterprise forces are combining to define “QoE” in a way that depends more on the applications and their hosting than on their connectivity. For operators, it’s going to come down to whether the VPN-centric camp of enterprise buyers is diminished because of an implicit migration to the Internet and the cloud. There is a real chance that the Internet is going to be the universal connection fabric of the future, and if that’s the case then best-efforts wins, and operator service and customer experience management has to find itself a new role, one aimed at a kind of defensive QoE mission to avoid churn.
