Everyone who’s read my blogs knows that I believe that “metro” is the value bastion of the future for network operators. Juniper did a “Cloud Metro” announcement over a year ago, the first and most significant such announcement by a network vendor, and I’ve been waiting to see how they developed the theme. That question may have been answered with new Cloud Metro material and a blog to flesh out the story further, but more refinement seems essential, down the line.
To understand my view on Juniper’s Cloud Metro, you need to understand both the announcement and why I think metro is important. Networks are, for a variety of business and technology reasons, not homogeneous structures but rather layered structures. There’s an access network and a core network in classic thinking, and the place where the two come together is usually called “metro”. In population demographics, a metro area is a population center that almost always consists of multiple communities that operate as a somewhat cohesive commercial unit. A lot of modern thinking would argue that the boundary of a metro is the distance across which commuters and shoppers are willing to travel. A metro is thus an economic unit.
Technically, meaning in networking terms, metro locations were first the transit switch locations in telephony, then the boundary of the central office locations connected to a common fiber ring. The technical boundary grew out of the economic boundary; people tended to talk/interact with others they could also reach physically, and even companies tended to define their organizational hierarchy based on “regions” that were often metro areas.
As networking has evolved under the pressure of broadband Internet and mobile networks, the metro area has taken on added significance. Interests of all sorts center there, and those interests create service opportunities. Realizing service opportunities these days means The Three “C’s”, combining computing, content, and connectivity, and metro areas offer an ideal place to do the integration because there’s enough traffic/value density there to justify the resource investment. This has been true for at least a decade, but for most of that period both operators and vendors have been slow to recognize the need to evolve metro technology to reflect the evolution in metro missions.
The biggest change in metro architecture and technology is a shift in technology driven by a clear shift in the creation of service value, those Three “Cs”. Telephone switches created service value for voice, and early data networks (T/E-carrier leased line) created value through connectivity. Today it’s features and content that create value, which means that value hosting in metro networking evolves the metro toward data-center-centricity. You can expect the largest concentration of servers hosting features in the metro area because it’s deep enough to create economy of scale and shallow enough to support user awareness and personalization.
Let’s now move to Juniper’s Cloud Metro. In a presentation in the UK last week to launch the vision, CEO Rami Rahim said that it was clear dumb pipes weren’t going to cut it any more; “we need something better”. That’s the fundamental truth of metro in a nutshell. However, the Juniper slant in Rami’s pitch is till aimed less at going beyond dumb pipes but in making dumb pipes more efficient. There’s nothing wrong with that at one level; telecom services are connectivity first and smarts second, and you can’t have connectivity services turn into a loss leader. At another level, you can’t get beyond dumb pipes with connection efficiency alone. The question for Cloud Metro is what adds the essential smarts, meaning where does the “cloud” part come in.
In some data center, obviously. The centerpoint for data-center-centric metro is a highly service-capable fabric, which Juniper provides with its ACX7000 family. An agile fabric is essential in supporting the multi-tenant, multi-service, metro value model and you need IP switching rather than pure Ethernet to keep the pieces and service types separated as needed. The Juniper switches have packet-forwarding engines that can turn off unused capabilities to reduce power consumption. They’re supported by 400G coherent optics that integrate the optical layer with IP. This combines to build the connectivity needed for value hosting, at the metro edge.
To me, the key differentiator for the new metro is tight integration with a local data center, meaning “edge computing”. That requires connectivity, but also a vision of what I called “value hosting” above. The presentation introduces the old model of metro as “retro metro”, and in it we still see the Cloud Metro vision as an evolution of connectivity. Traffic will increase, capacity will explode, and the mission of connectivity will become more difficult to operationalize, secure, and make sustainable. Again, all of this is true as far as it goes.
The “new metro” model is certain to be significantly more operationally intensive than the old fiber-ring model, not only because of the increased technology breadth in metro but also because of the wide variety of service missions, each of which are likely to involve specialized management. Juniper Paragon, its wide-area AI-driven automation tool, provides the baseline FCAPS support, and because metro centers are expected to grow as new services are added, it’s augmented by AI-Enabled Device Onboarding-as-a-Service and Paragon Active Assurance, which uses embedded test agents to make the metro network into what’s essentially a big distributed sensor that can also simulate traffic for active testing.
The multi-technology, multi-service, evolving-infrastructure nature of metro poses special security challenges, and Juniper adds Zero Trust Security to Cloud Metro, including threat detection, analysis, and protection, and strong digital identity proofs via the Trusted Platform Module. Critical platform files are encrypted for transport, and security measures and state are validated by Paragon.
What this adds up to is a Cloud Metro framework that defines how metro networks will be supported as they evolve from simple fiber interconnect to feature hosting points and edge computing centers. Juniper was the first of the network vendors to recognize that the metro of the future was very different, and they’re now productizing the tools to accommodate metro evolution. Every element of their Cloud Metro story is relevant, but one element seems missing…the cloud piece.
The latest release says Juniper “announced the innovation that will power its vision and strategy for Cloud Metro – a new category of solutions for service providers, optimized for metro transformation and sustainable business growth.” The “new category” comment is carried forward in the webinar and the blog entry I link to above. New product categories are a sort-of holy grail for vendors. If you can establish one you are for a moment able to define how the category will be judged and set the bar for how vendor comparisons within it will be aligned by features/capabilities. The first vendor gets to define the columns in the comparison chart, the quadrants in those pervasive market position charts. Does Juniper really want to do that, and if they do, have they done enough?
Let me start by saying that metro should be a new product category, because as I’ve noted, metro is the feature repository for the future of network services. That’s the real value proposition here, and it has the advantage of being something new, and credible…and exciting. News, whether it’s tech news or any other kind of news, means “novelty”. Juniper achieved that in its announcement last year, but can further novelty be achieved without really smartening those dumb pipes? Can it be achieved with technology that’s not targeting specific new service/experience missions? If not, then those missions have to be defined and the fulfillment has to include pipe-smartening, and there was very little about that in the latest announcement.
Media coverage of Juniper’s announcement has focused on 5G, apparently because that was the hot concept the media could link coverage to. 5G is clearly not going to revolutionize metro by itself; at most it’s a way of getting operators to think about what adding feature hosting to connectivity could mean. It’s a potential way of getting started with edge computing, with hosted features, with smartening dumb pipes. Those things should be the story, and ironically I think they are the story that’s inherent in the technology.
This raises the question of what would revolutionize metro and launch edge computing. Servers and platform software? Cisco has more credentials in that space than Juniper, which might not be a good thing. Operators are unlikely to embrace a single-vendor model, so Juniper could be smart in not pushing a specific server/software mix for Cloud Metro. Still, they will be required. Could Juniper launch Cloud Metro without the cloud part, or with no cloud connection other than 5G function hosting? That’s not a revolution, not exciting, and probably not a new product category. So what must Juniper do? Juniper could embrace a model, an architecture, rather than risking someone else suggesting one. That would lay out a vision of how the cloud and metro networking fuse.
“Cloud Metro” has to start with cloud in more ways than sentence structure. Yes, feature-hosting centricity in metro would require changes to the connectivity elements there, but it’s the feature-hosting piece, the stuff that integrates with edge computing, IoT, the metaverse, and so forth, that’s driving all of this. Simply preparing for the network changes puts you at the mercy of those who can drive it.
Juniper actually has the best, most complete, network product solution to support the metro of the future. However, their own stuff can’t bring that future metro about; they need servers and software and architecture to make that happen. Rather than doing the first two things on their own, a move that would help position Cisco (who has more of that stuff already), they need to create something that others can buy into…and make that exciting and revolutionary.
Can a new product category be justified without this sort of excitement-building talk? No. Even if the concept was a real technical framework, analyst firms won’t sell reports and make money off that sort of thing. A new category has to be a revolution, one that as many players as possible will understand and want to be a part of, and buyers will accept and want to evaluate. Making that happen has to be Juniper’s next Cloud Metro step.