Back in February, Juniper did a couple of blogs on Juniper announcements, opening a question of whether Juniper was getting ready for some major positioning changes. I noted that in this blog, and suggested that perhaps Juniper was making some major virtual-network changes, ones that could even end up impacting Juniper’s Cloud Metro story and positioning Juniper in the metro space in a decisive way. On March 17th, they announced Apstra integration with their CN2 positioning, asking “Why are our data center and telco cloud customers so enthusiastic about the CN2 and Apstra integration?” Why? We’ll see.
Juniper’s blog post on this opens some points of interest for prospective metro applications. One thing that general function virtualization demands is the ability to host on pretty much anything, including VMs and bare metal. However, the optimum platform for most virtual functions would be containers, and the optimum orchestration strategy would be Kubernetes. CN2 supports that, and now Apstra can manage the switching fabrics in the data centers where mixed hosting options for virtual functions could be critical.
If you believe in service features, you believe in metro feature hosting. If you believe in edge computing, you believe in metro feature hosting. In fact, there’s not much new or exciting in either telecom or cloud computing that doesn’t absolutely depend on metro feature hosting, which is why I have a hard time understanding why vendors haven’t been all over it for years. Even given the fact that telcos are dragged kicking and screaming into anything, it seems, beyond tin cans and strings, it should be clear that somebody has to grab some arms and legs (and ear plugs) and start pulling. And all the drivers involve hosting, so data center integration with access and aggregation in one direction, and core connection in the other, mean metro is a big technology junction point.
Which is why I think Juniper may be getting more serious about it. Keep in mind that however much core-on-ramp or access aggregation goes on in the metro, it’s the feature injection piece that’s driving the bus, requirements-wise, and if you’re not going to build features you have to prep for unified hosting and management. I think Kubernetes and CN2 are two legs of an evolving metro stool, and the Nephio project is the third.
Let me quote the Nephio mission: “Nephio’s goal is to deliver carrier-grade, simple, open, Kubernetes-based cloud native intent automation and common automation templates that materially simplify the deployment and management of multi-vendor cloud infrastructure and network functions across large scale edge deployments. Nephio enables faster onboarding of network functions to production including provisioning of underlying cloud infrastructure with a true cloud native approach, and reduces costs of adoption of cloud and network infrastructure.” Juniper is a Nephio participant.
The point here is that Kubernetes is what makes the cloud go around. CN2 is what extends the cloud’s virtual networking to non-containerized, even non-cloud, server assets, and Nephio lets Kubernetes manage related network assets. The three combine to define the glue that ties all the various technologies in metro into a unified, manageable, entity. Not only for telcos, but for any public cloud providers or interconnects that want to play in function hosting and/or edge computing, which means pretty much all of the above.
All of this raises interesting opportunities, questions, and challenges, and not only for Juniper. As I noted in my referenced blog, Juniper has significant technology assets that could be highly relevant in the metro space. So do other vendors, most notably Nokia, who’s the topic of a blog I did earlier this week. Nokia hasn’t done much in the way of explicit metro positioning, but Nokia has a handle on the edge opportunity, and that’s driving the feature bus. Juniper has a position on the network side. The point is that if feature injection is the goal of metro, even Kubernetes-based operations is a long way down the stack from the features we’re trying to inject.
We’re really looking for a harmony of hosting and network to create a standard development platform and encourage feature production. That means that it’s not Nokia alone that could threaten Juniper’s potential metro evolution, so could other players not even in the networking space. While real threats would be solidified in a full set of “feature middleware”, there are intermediate things that could be done to both step toward that feature goal and provide some interim solutions to feature-hosting problems, in part by creating some unity between NaaS and PaaS. That’s particularly true if we generalize “feature hosting” to mean “edge computing”.
Tenant management in edge computing, and the related topic of tenant security, is way more critical than in the cloud. That’s because edge computing is really justified only for real-time applications, and real-time applications connect to the real world, where mischief could create a disaster of major proportions. That, I think, means that virtual network control is absolutely critical at the edge, and it has to meld the Kubernetes notion of virtual networks (which is the cloud/container view) and the network view. Unity, stroke one.
The next point is that we can’t have people writing edge apps for bare hosting, in large part because of that security point. Keep in mind, too, that security at the edge means more than keeping out bad actors, it means ensuring that Real Time A doesn’t somehow hog all the resources, bringing Real Times B and so forth to a grinding halt, even if it’s an accident and not malicious. Thus, we need middleware, and probably several perhaps-related-at-some-point middleware stacks. NFV hosting, if it evolves to become relevant, needs a specific middleware kit. Edge computing needs a middleware kit at the general level, with perhaps specialized stack top-offs for classes of applications. Some of this middleware will have to influence connectivity. Unity, stroke 2.
What’s important here is that none of our network vendor contenders has, as far as I know, any activities relating to the creation of this middleware, which would create both a NaaS and a PaaS element for the metro and its interconnected partner feature components. The question is then where thus stuff would come from, and there are three possibilities I can see.
First, some vendor in or out of the networking space could step forward with an architecture and and software prototype, and do the job. This would move things the fastest because a single hand on the reins moves the team best.
Second, some similarly constituted vendor could step forward with an architecture, and launch an open-source project to realize it. Juniper did something like this with IPsphere decades ago. This could also move things along quickly, but the risk is that open participation would lead to the inclusion of players who really wanted to interfere with rather than make project. Cisco was that player in IPsphere; maybe here too?
Third, somebody could launch a standards or standards-like initiative like Nephio or the NFV ISG. This would be the worst possible outcome because it would move at a glacial pace, satisfy nobody because it was trying to satisfy everybody, and stall any other initiatives with the same goal because nobody wants to step on a standards process.
If none of these options look likely, or at least look like they might be effective, what about non-network vendors who might jump in? The most obvious source of these new competitors would be the public cloud providers, and perhaps Google in particular given their connection to both Kubernetes and Nephio. VMware and Red Hat could also play from the software platform side. I’d rate the chances of a player in this non-network group stepping up as being slightly better than that of a network vendor stepping out of their usual comfort zone.
There is, of course a final implied possibility, which is that nobody does anything. Over the long haul, I think that would lead to a bunch of silo implementations that would fight it out and divert developer and other resources until all but one or two of them were killed off. That would take five or six years, and would delay full realization of the potential of metro, edge computing, and new and revenue-positive telco services. I hope somebody steps up, and I think that they will. I suspect that within a year, we’ll either see a potential answer to the problem of NaaS/PaaS unity at a higher level, or we’re in for a half-a-decade slog.