How will my company win in 2021 and beyond? This is a question that every networking giant and aspirant is already facing, and will face even more in just a few months. The global economy is going to start to recover next year, and with that recovery will come a lessening of fears about broad economic impacts on networking. That leaves the network-specific fears, fears I’ve talked about from the perspective of operators in past blog. Now, it’s vendors’ turn.
The problem with network equipment sales is the same for the enterprise and service provider spaces. In both cases, return on investment for new network technology has been steadily harder to create. On the enterprise side, that’s because we’ve not had a transforming new productivity paradigm in two decades, the longest period of drought that the market has faced since the dawn of IT. For service providers, the problem is the steady slippage in profit per bit, a reflection of the fact that “connection services” are just plumbing in the Internet age. Lower ROI is the universal problem for vendors, but not all vendors face it the same way.
There are four classes of players in the networking space as we enter our new age. The first is the incumbent network equipment vendors, the second the hosted function supporters, the third the public cloud providers, and the last the white-box players. We’ll take a look at issues and options for each.
Our first group is probably under more threat than any player in the space. Both enterprises and service providers have been under “benefit pressure” for a decade, which means that they’ve struggled to make a business case to raise capital budgets. For enterprises, the problem has been a lack of a new productivity paradigm, and for service providers a steady decline in profit per bit. That’s resulted in downward pressure on pricing for network gear, and the explosion of interest in open-model networking of some sort.
The strategy of vendors so far has been to discount where necessary, but with the troubles being faced by price-leader Huawei, the discounting strategy has been less effective, and I think that’s had more of an impact on the purchasing of traditional network gear than the pandemic. I also think it’s pretty obvious that vendors are not going to be able to raise discounts without destroying their own bottom lines.
That means the network vendors need to do something I’ve told them to do for a decade, which is to help buyers find the business case for more purchasing. The only near-term opportunity to improve network benefits is to promote a network-as-a-service model. Naas lets the network itself assert APIs to provide needed features to applications, making it unnecessary for application-layer or middleware technology to do save the day. This is so important that I’ll say now that NaaS is the near-term goal for all four of our classes of network player.
Among the network vendors, Juniper is the only one who seems to have a NaaS strategy. The acquisition of Mist, 128 Technology, and (just recently) Apstra, gives Juniper all the pieces needed to create a NaaS story quickly, which would then give Juniper a jump on the market if I’m correct and NaaS is the way to go. Juniper, not a vendor I’ve picked in the past for strategic leadership, could now be out in front overall.
The group of vendors who seemed most likely to knock off the big equipment giants is our next category, the hosted-function or server-based network players. This group has a big disadvantage out of the box with its tie to NFV, a technology that didn’t get off to the right start and hasn’t been able to shed its ineffective base model since.
On the surface, NFV should be a great platform for NaaS because it postulates the creation of services by deploying and linking functional elements. The problem is that NFV got way too deep into per-customer service enhancements, notably security, and never really focused on what I’d call “infrastructure services”, the functional platform technology that creates multi-user services like the stuff NaaS has to be based on.
The major players in this group are software vendors like Red Hat/IBM, HPE, and VMware. The latter has what I think are the best technology assets to address NaaS, but its positioning and messaging has been very NFV-centric. There is no chance, in my view, that NFV could possibly create a technically optimal model in the NaaS space before the major network vendors (Juniper, notably) does it, which means that all these vendors, including VMware, will have to jump onto a different, better, bandwagon.
To do that, they’ll need a “camel” a leader-concept that can showcase a shift in positioning and justify it at the same time. It’s very clear that Open RAN is the camel here. If the hosted-function players can get a strong Open RAN story that embraces basic technology shifts applicable to the network at large, they can win here, and fairly quickly. Maybe quickly enough to take the lead and shape the NaaS space. The 5G User Plane Functions, for example, are perfect hosted elements of a NaaS.
The problem here goes back to NFV. There is no credible way that servers are going to replace all network devices. In fact, the current trend is to say that the data plane of current IP elements is going to have to be migrated to white boxes if open-model networking is the goal. That means that what gets hosted by hosted-function players is the IP control plane, as well as the “control plane” of services like 5G RAN and Core, CDNs, and (eventually) IoT. Right now, the hosted-feature guys are not engaged in white-box-symbiotic positioning, so they’re disqualifying themselves from this critical relationship, and perhaps from NaaS.
I think VMware is the player to watch in this space. The future of hosted-control-plane IP and control-plane function hosting for higher-layer services lies in bringing cloud-native to these areas, not NFV. If VMware can position its broad cloud portfolio, which is more valuable to the NaaS future than their NFV stuff, at hosting the control plane of all current and future services, then they’ll be able to quickly set a standard for the future network. To do this, they’ll need to embrace white boxes as subordinate elements to the cloud, or they’ll empower the last two groups of vendors.
The public cloud providers have recognized that 5G in general is the mission for server resource pools in the network of the future. Since network operators rarely capitalize anything but current service opportunities, it’s the mission that could induce operators to start to deploy their own cloud technology, the “carrier cloud” that could generate a hundred thousand new data centers by 2030 if it reaches full potential. Obviously, cloud providers 1) don’t want operators building that kind of cloud, and 2) want to make money by hosting the service missions that might drive it. That means, right now, Open RAN, and it’s why many of the cloud providers are focusing on it.
Many but not all. Google is taking a bold position in its Google Mobile Edge Cloud (GMEC), looking at 5G driver applications rather than 5G infrastructure elements. Google is betting that other cloud providers won’t win a significant advantage in hosting Open RAN, in no small part because that’s a competitive focus for all the other vendor categories and it’s always wise to avoid betting on a free-for-all to gain advantage.
The problem with Google’s approach is that operators have been really bad at selling anything other than connection services, and most have been stalling and diddling to avoid even considering that move seriously. They want vendors to do their job, and of course Google may see themselves as doing that by providing some nice horizontal and vertical applications in hosted form. But once you give operators an application in hosted form, all wrapped up in a nice technical bundle, you just move the objections to the selling side. Operators have limited sales capability in the first place; they’re order-takers. Second, they have zero engagement with the line organizations that buy applications. This means Google is either going to have to do some astonishing hand-holding of operators, or launch a major marketing campaign that operators can piggyback on.
And now our final category, the “white-box” players, and this group has three sub-classes. The first is the white-box players who propose to run open-source switch/router software on white boxes to create open monolithic switches and routers. The second is the SDN players who see white boxes as the data plane of the future network, and SDN controllers as the control plane. The ONF, technology driver of this group, has started promoting “programmable networking” as a benefit of this approach, and that’s (so far) the only NaaS-like positioning out there. The final group is very limited in size; it’s the group of white-box vendors who build up nodes of any size by clustering white boxes.
The advantage that our second sub-class, the SDN gang, has because of the ONF’s programmable-networks story is somewhat dissipated by the fact that the ONF is a specification body, and their insights impact the market only if somebody implements and sells the ONF story. At the switch level, SDN is commonly used in the data center, but as a general forwarding-plane element or as the data plane of IP, there’s nobody carrying the flag in this space as far as either operators or enterprises are concerned.
Besides the “no-obvious-seller” problem, the biggest problem in securing a position in the control plane of a programmable strategy is the buyer fear of a central controller, a single point of failure whose risk gets bigger as the scope of deployment expands. The second-biggest problem is that it’s far from clear just how SDN-generated programmability translates into NaaS.
The white-box-cluster group is currently being defined by a single player, DriveNets. They advocate a whole list of advanced concepts, including separation of the control and data planes, the ability to host third-party service elements in cloud-native form, and the ability to present the cluster as a single element to other routers and to management systems.
This combination would make it easy for DriveNets to deploy a NaaS story, but so far, they’ve not done that. Their current focus has been in displacing routers in deeper-than-5G missions; they won the AT&T core network, for example. That shows that the cluster approach works as a router of any size, but it doesn’t validate either 5G or NaaS, so if those are the key elements in the current battle for network transformation, they still have stuff they need to do.
Where, then, does all this lead us? Juniper, I think, has built the easiest path to NaaS by creating an ecosystem that can deliver personalized, experience-centric, connectivity that can be integrated vertically all the way down to transport. They also, with Apstra, have an intent-model technology that could simplify management of services and infrastructure. Play intent modeling right, and you solve how to cloud-host features. What they would need to add is just an explicit way of linking this to 5G Open RAN and NaaS beyond connectivity. That could be done almost by positioning alone, but they could also ally themselves with other platform players in the hosted-feature space, and integrate it with intent modeling.
The challengers to Juniper, IMHO, would be VMware and DriveNets. VMware has cloud creds aplenty, and the mass and market influence to do something profound, providing they also have the vision and determination. They only have to rise above NFV to do it, too. DriveNets is technically the closest competitor, but they’re a startup and it’s not yet clear how they’ll expend their technical bandwidth and media collateral. NaaS and the future of open networking is, after all, more future than current, and so they have to balance the strategic with the tactical. Can they make the right choices? If so, they have a shot.
For all the rest of the players, the big question they have to answer is how they’d implement that same beyond-connectivity NaaS, starting with how they could play a role in Open RAN. That starts with a vision, and it has to be one that links the “control plane” of Open RAN, CDN, and IoT, with the separate control plane of IP, and with white-box generalized forwarding.
Who could win it? Almost anyone at this point, but I think that it’s very possible that the space will start seeing cohesive positioning by spring, and after that the windows will start to close for more and more of the players. This is one of those times when nothing short of naked aggression will serve, and that’s never easy for any vendor. We’ll see who steps up, and then grabs the best chance of shaping the future.