I don’t think anyone is surprised to hear that I think “metro” is the hot spot for the network of the future. I don’t think many are surprised when I say that Juniper has been, shall we say, dabbling in metro for over a year. I use the term “dabbling” because while they’ve announced “Cloud Metro” and have made a number of announcements I think are linked to the space, they’ve not moved aggressively to claim leadership there by building on the announcement of Cloud Metro with later announcements of supporting technology.
When Juniper announced their Converged Optical Routing Architecture (CORA) I was curious to see whether they’d be more metro-aggressive, and I think they have done so. Their solutions page for CORA mentions “metro” ten times. Best of all, they explicitly link CORA to Cloud Metro. Their website also frames the story of metro pretty darn well, calling it “The “new edge” where connectivity, distributed cloud, and customer experiences converge.” It seems to me that Juniper is working to take ownership of metro, and I’ve seen the view of operators shifting to reflect that. In January, only 8% of operators I chatted with said Juniper saw “metro” as a critical point of infrastructure evolution, and in June the number was 58%.
Why, you may wonder, is Juniper’s metro positioning important now, with CORA? In part because of that shift, and particularly because a part of the reason behind it is that operators are themselves seeing metro in a new light. The truth is that until roughly the beginning of May, I wasn’t seeing too much specific operator focus on metro. Now, I do. And CORA, as a converged optical routing strategy, is very likely to figure strongly at the point where “connectivity, distributed cloud, and customer experiences converge.”
As I noted in this blog, metro is the optimum place for hosting additional non-connection service features, to support things like IoT, the metaverse, and any general edge computing applications. The reason is that it’s deep enough to be able to provide economies of scale superior to on-premises edge hosting, supports a wide enough geography to cover most key applications in industries like energy and public utilities, and close enough to the user to have low latency connectivity.
Metro hosting in itself would make metro network points critical, but once we accept a metro-centric infrastructure those metro points become an even-more-logical dividing line between access and core. The majority of CDN cache points are already located proximate to metro centers, and the demarcation points for ISP connections to the access network are often located there as well. We could argue that (for example) the US infrastructure of the future would consist of 380 (roughly the number of metro points in the US) access enclaves with metro points linking them to the core. That means that we could also say that the role of the core would be linking those metro points, which is where CORA could come in.
A metro point’s logical service area, about 400 square miles, isn’t an absolute limit to the scope of an edge-hosted application. Some utilities have much broader service areas, for example, and that could mean that some utility IoT might need to spread out a bit more than a metro. The logical way to do that would be to provide low-latency links between adjacent metro areas to create a kind of regional complex. This would be a great mission for direct optical meshing, which of course CORA could provide. We could then look at meshing regions in a similar way, creating a low-latency minimal-hop network that could cover an entire country.
This model could also perhaps serve social-metaverse missions too. Many social-metaverse applications, even those that aren’t explicit social-networking targeted, could have a very wide geographic scope, and latency clearly creates problems in realistic avatar interactions in a virtual world. Gaming creates this same problem if it’s a multi-player game or if some or most of the scene and character generation has to take place beyond on-device hosting. And, of course, connections from metro to cloud provider could also be low-latency and that would enhance QoE for cloud applications.
I don’t think there’s any doubt that Juniper, particularly with CORA, has the tools needed to create a metro-centric infrastructure that’s well-suited for IoT and metaverse applications. To me, the primary question is one of activism. It’s one thing to create the tools needed and then wait for the buyer to recognize the need, and another to promote the missions that mandate the tools. I think Juniper could still do more, a lot more, in the latter area.
One hundred percent of telcos tell me that IoT is a future mission that could justify edge computing, though as I’ve noted they tend to be a bit fuzzy about where the edge is and thus don’t necessarily see metro-centricity as the model. The problem is that the telcos really don’t understand the drivers or see promoting those drivers as their responsibility. It’s not difficult at all to define the key verticals in IoT, metaverse-of-things, and so forth. I’ve already noted that Nokia does this quite well for private 5G. What’s a bit surprising is that even Nokia hasn’t been aggressive in promoting a mission-centric marketing vision for edge computing or metro.
Some telco tech planners, perhaps a third, say that they believe vendors should promote missions like the metro missions. Some of that view is surely rooted in the fact that these planners know their own organizations are under-promoting any missions other than connectivity. Some is rooted in the hope that vendor initiatives would convince senior telco management, and some in the hope that better vendor promotion would raise the media profile of these missions, which would then address both the other hopes.
I think that vendor promotion alone isn’t likely to solve the problem, though I do think that this sort of promotion would benefit the vendors themselves. The challenge with non-connection missions that would be needed to drive any higher-level features or any edge hosting (wherever you think the edge is) require application and software platform elements. The best way to get that sort of involvement would probably be some sort of industry group. I don’t say “standards group” because telco standardization tends to take root in connection evolution and become a tree.
For Juniper and all its competitors, the notion of an industry group comprehensive enough to move the ball in metro and edge hosting is a risk. Because the drivers would be more easily supported via software than via networking gear, another whole class of players could end up entering the game…and even winning. IBM/Red Hat and VMware (particularly if the Broadcom deal goes through) would be in a good position to frame out the architecture for the feature-hosting part of the puzzle.
The good news for Juniper is first that those new competitors could have entered the space two or three years ago, even before Cloud Metro came along, and they didn’t. Why now? Second, because of the 5G deployments and capacity demands, operators are looking for some modernization and thus could be influenced by a logical metro strategy. Right now, Juniper has the best metro strategy, and with CORA they’ve demonstrated that they’re gradually making metro more strategic. They could win this.
