Over the last two years, I’ve been pretty clear regarding the importance of virtual networking. It’s not only that the use of the cloud, and the expanded use of virtualization and containers in the data center, demands it. SD-WAN is a form of virtual networking that’s exploding as a means of connecting thin sites and cloud components to the corporate VPN. Finally, it’s inevitable that the Internet becomes the dominant means of connecting both consumers and businesses, and the latter application demands virtual networking for traffic segmentation. It also promotes Network-as-a-Service (NaaS) in its broadest sense, which further exploits virtual networking and may well link SD-WAN with the other virtual-networking models.
I’ve also been clear that I believe Juniper has the strongest product line of all the vendors in the virtual networking space. They have their Contrail virtual-network technology, they acquired what I believe to be the premier SD-WAN tool with 128 Technology, and Mist AI gives them a foundation for automation of network operations, something critical in the highly dynamic and essentially fuzzy world of the virtual network. But I’ve also been critical of Juniper’s positioning of their assets in the virtual network space. Innovative products require innovative messaging, and recently there have been some signs that Juniper is getting more serious about singing their virtual-networks song.
Containers have become the go-to application hosting model for most enterprises, both within the data center and in the cloud. Kubernetes is the preferred container orchestration tool, but even large enterprises have concerns about adopting open-source software in its native form, compiling the source into loadable units, and maintaining all the other elements of a container ecosystem. OpenShift from Red Hat is a supported container platform that includes orchestration, and one of the elements of the platform is the Container Network Interface, a plugin that provides containers with virtual-network capability. Juniper had a Kubernetes plugin for Contrail, and now it’s released CN2, which is a virtual-network SDN/CNI strategy for OpenShift.
Juniper has taken steps to integrate CN2 tightly with OpenShift to make it easier to install, and easier to adopt for companies that already have a CNI strategy (which, realistically, is most OpenShift users). This is particularly valuable for companies who are looking to integrate their data center virtual networks with their cloud networks in a hybrid cloud configuration. Given that IBM (Red Hat is an IBM company) is one of the leaders in promoting hybrid cloud strategies for enterprises, this gives Juniper a hook into what might well be the most critical applications of virtual networking, and thus of networking overall.
Juniper also announced its “SD-Branch” strategy, which combines Mist AI management (via the Juniper Mist Cloud) with the Session Smart Routing Juniper acquired with 128 Technology. In this announcement they’ve not only tied in AI, but also the assertion that the explicit connectivity control offered by Session Smart Routing is a key piece of zero-trust security and enhances security overall. Other Juniper security tools can be layered on to this framework. Finally, the SD-Branch bundle includes Marvis Virtual Network Assistant, a tool to provide easy operations support for complex multi-technology networks that include SD-WAN.
These two virtual-network-related announcements were blogged about on the same day, which certainly raises the question of whether Juniper might be looking at creating explicit integration between the two. Such a move would do a lot to unify Juniper’s own story, and also to address the fact that a business network these days is increasingly a composite of the Internet, a VPN, the data center network, and the cloud network. Could Juniper be planning to unite its virtual-network families, and by doing so create a truly universal virtual-network model?
In my earlier blog on NaaS, I pointed out that NaaS couldn’t be simply a usage-priced VPN, in part because the Internet and the cloud foreclosed such a simple vision. CN2 and SD-Branch could be combined to create a true, highly functional, NaaS framework that would embrace current VPN commitments (and even true private networks) and at the same time be suitable for the inevitable shift toward using the Internet broadly for cloud and business connections. Not only that, I think that those capabilities are already in place so it’s just a matter of collecting them into a kind of super-product. Since Juniper is unique in the features it already has, this would give Juniper a major lead in the NaaS space, and I think that “true NaaS” is where networking overall is heading.
The same moves could give some life to Juniper’s Cloud Metro story, which is IMHO the most critical transformation of our time in network infrastructure. As I’ve said in many blogs (in many ways, too!), the metro piece of the WAN is the most critical piece in terms of infrastructure evolution. It’s close enough to the edge to allow for personalization, which makes it a critical place to inject service features. It’s close enough to be reached with low-latency connectivity, which means that all real-time applications that evolve out of IoT, the metaverse, or a combination of the two will likely have to be hosted there. It’s also, as the logical edge of the core network, the place where any optically intensive core transformation will have to take place. In short, if the Internet is really going to become universal, it’s likely the metro deployments that will launch any technical changes designed to facilitate that universality.
You could argue that yet another Juniper blog, this one on Apstra’s importance as a data center automation platform based on intent modeling, is an important metro step. Metro isn’t just networks, it’s also hosting, which means that it’s an edge data center. Could Juniper be looking at Apstra as an element in metro? The Apstra blog was five days before the CN2 and SD-Branch blogs.
Those who have followed my views on Juniper, NaaS, and metro over the last couple years will likely realize that what I’ve said they could do here hasn’t changed much in that time. What may be changing is Juniper’s intent, with the emphasis the key factor here. We’re on the verge of the biggest service transformation in the history of networking. Therefore, we’re on the verge of the biggest network infrastructure transformation, and the biggest transformation in the stuff that builds the infrastructure. Could Juniper’s announcements be an indicator that it’s really going after this Great Transformation? If so, and if they succeed, then we could be in for a very interesting 2023.