Fusions of networking and cloud aren’t new, but it’s at least novel for such a fusion to be proposed by a network equipment vendor rather than a cloud software vendor. Similarly, it’s not news that the metro portion of the networking is the key to the network overall, but it’s at least novel to combine this point with the cloud. Juniper’s “Cloud Metro” announcement targets exactly what the name suggests, and Juniper has an impressive set of assets in play in the space, perhaps the best in the space. Do they play them in the announcement? We’ll look at the demand side, the justification, first, and then see how well Juniper does in addressing it, both technology-wise and in positioning.
The largest source of traffic on the Internet is video, and the majority of that traffic is delivered via content delivery networks (CDNs). This is true, but not new. Edge computing would be located in the metro area, if one counts access as part of metro. Also true. 5G, and in particular O-RAN and open-model 5G, will rely more than ever before on hosting of features, and the place that’s likely to happen is in the metro. All this means that Juniper’s opening thesis on their Cloud Metro story is true, but that any novelty in it has to stem from edge computing and 5G, and I contend that the two are symbiotic.
CDNs are hosted elements, and of course edge computing and 5G O-RAN require hosting too. Hosting here means “resource pool”, which means “cloud computing”. We can see that association in the cloud providers’ interest in both O-RAN/5G and edge computing. We can see it in the “Telco Cloud” initiatives of HPE, IBM/Red Hat, and VMware/Dell. You don’t get competition from multiple segments of the market for an opportunity area that has no realistic justification. Juniper, representing network equipment vendors, surely sees their position in the metro threatened by wholesale substitution of cloud technology for network equipment. They need a metro story, and they’ve created one.
“Cloud Metro” is the tag line for Juniper’s story, and it’s a good one. The metro sites of networks are where the action will be, where all the traffic and feature injection issues resolve optimally. There may be edge computing, but the big resource commitments will be in the metro, making each metro area into what is in effect a distributed data center.
Juniper believes that the revenue opportunities represented by network services are rising up, not perhaps as high as the OTT space but certainly higher than bit pipes. The new features that will cement the value proposition for these new services are hosted as functional elements and then assembled into cohesive experiences. The process of assembling them has to include threading workflows among them, which means throughout the metro area.
Old-time services were linear delivery pipes, and new services will be mazes of work exchange among functional components, creating that stuff known as “horizontal” traffic, just as it has inside data centers. The solution is to create a “metro fabric” something that can provide high-speed exchanges for that mesh of function traffic.
The metro fabric is created using high-speed interfaces on Juniper’s aggregation products, and two new high-end aggregation switches are included in the announcement. These are combined with flexible traffic steering for connections, automated operations to ensure that the added workflow complexity doesn’t drive up opex, and a more sophisticated monitoring capability that lets operators understand more about the state of services, rather than focusing on isolated boxes and trunks.
As part of the metro fabric, Juniper is bringing a form of 5G-like slicing to an IP network. While they’re not saying this is totally 5G compliant (the standards aren’t done yet), they are participating in the 5G standards process to ensure their stuff tracks the 3GPP. The slices can be used by any service, and they create transport traffic classes that can be used to separate things based on differences in QoS needs, or simply for security isolation.
Perhaps the biggest piece of the announcement is Paragon Automation, which includes some Juniper stuff (Netrounds) and third-party elements. The goal is to allow operators to define “script” responses to network events or network tasks, which both simplify operations and reduce errors. The Netrounds piece is especially important because it introduces active service quality assurance rather than relying on explicit failures to trigger actions.
There is a metro demand. There is a strong indication that 5G and O-RAN will expand it. If IoT is real, that will contribute more, and my drivers for “carrier cloud” would deploy massive cloud-like resources to the edge. In short, there is a real opportunity here for Juniper to realize. Juniper’s Metro Cloud approach does address the opportunity in a practical and sometimes creative way, but the real question is whether Cloud Metro moves the ball in a way that would be compelling to buyers.
Network vendor strategies, in general, tend to be sales-cynical, meaning they’re designed to be positioned effectively rather than to address the actual opportunity at the technical level. Juniper is a network vendor, and their own positioning has IMHO blown market-hype kisses while generally falling far short of the potential of their technology.
There is nothing really new in Cloud Metro, making it more a solution architecture than a product announcement. Since it’s made up of fairly conventional pieces or third-party tools, Juniper’s competitors could launch a counterpunching attack. Could Juniper’s Cloud Metro really hold a place in a “cloud metro” world? To be assured of success, it would have to meet three tests. First, the positioning would have to address a simple truth, which is that server-hosted high-capacity routing is not the right answer. Boxes and hosting will coexist. Second, the positioning would have to include something specific with regard to O-RAN, not just a pleasing smile in O-RAN’s direction. Finally, there would have to be some specific data center hosting element to the story, to offer a reasonable positioning in “the cloud”. If Juniper’s technology and positioning measure up in these three areas, then the strategy behind their announcement is sound. If not….
The inevitable marketing lead-in slides in Juniper’s announcement deck don’t raise any of these points explicitly, which doesn’t necessarily mean that Juniper doesn’t address them, but does mean that it’s harder to pin down the specific ways that could be happening. We’ll have to get interpretive here, on our own.
I think that Juniper defends that first point adequately. The metro zone is the logical place where feature complexity would be introduced. It’s close enough to the edge that the traffic flows and performance requirements make feature customization at metro scale practical, but deep enough to concentrate enough resources to justify optimizing for economy of scale. The concentration of service features, almost surely hosted rather than instantiated in appliances, means there is likely to be a need for data-center-like horizontal traffic support, so “Cloud Metro” is an appropriate term for the collective infrastructure mission.
The second point, which is an explicit acknowledgment of the role of O-RAN in creating metro hosting, and support for that role, is less easily drawn out of Juniper’s position. They do show “vRAN” as one of those service-feature focus points in the Cloud Metro, and they do refer to the virtual CU and DU elements of 5G O-RAN, but they don’t reference 5G/O-RAN beyond identifying its transport elements (the CU/DU) as connection points to be served.
The final point, the need for a specific data center piece to the story, is the one I found the most surprising. Juniper acquired Apstra, which is a solid and innovative cloud data center strategy, but nothing is said about Apstra in the announcement. Given that arch-rival Cisco has data center products and has even adopted the “intent model” terminology that Apstra has used from the first, it doesn’t make sense to me to leave the Cloud Metro strategy hanging without a strategy to host the cloud. So much depends on buyers accepting this as a complete solution model, an all-Juniper strategy, that the hole in the story is not only hard to understand, it’s a risk.
It’s also hard to understand why Juniper didn’t work to tie in two other acquisitions, 128 Technology and Mist. The virtual networking features of 128 Technology could be highly useful in 5G control-plane traffic, and in the control-plane behavior of other services like CDNs. Mist technology could, at the very least, provide a managed services framework at the edge of Cloud Metro, in combination with 128 Technology. Why not make a big play, one that explains and addresses all the key trends? Why leave O-RAN hosting to a part of the user plane? Why not build the cloud data centers with Apstra and not just connect them?
Juniper has always had good, even great, technology. At the peak of its success just short of two decades ago, it also had great marketing and positioning. The former is still there, but the latter seems to have been lost. I think Cloud Metro could have been a much better tale to tell, and there are even pathways available to make it a great positioning, one that Juniper could hope to exploit and that they could also hope would throw competitors off-balance. It’s still a good concept, but not so much a good story, and Juniper needs one of those to prosper.
