Juniper Networks seems intent (as usual) on casting itself against Cisco Systems as the datacenter hardware vendor that accommodates software and openness.
It's been a heady few weeks of vendor announcements outlining visions for next-generation datacenter infrastructure, with Cisco Systems' long-awaited Insieme announcement garnering much of the attention.
Now, with Cisco's strategy finally part of the public record, it's a good time to take a closer look at another approach that slipped by with less fanfare in the days leading up to the big Cisco announcement (See Cisco's ACI Gets Physical With SDN and Cisco Asks the Killer SDN Question.)
Juniper Networks Inc. (NYSE: JNPR) announced its new SDN-ready MetaFabric for the datacenter and distributed datacenter networks at the end of October. It was Juniper's second big SDN announcement in recent months after the launch of its Contrail SDN controller, which included the announcement that, despite having its own controller, Juniper also would provide an open-source version of Contrail and would be willing to contribute its code to standardization efforts, such as OpenDaylight . (See Juniper Unveils Datacenter MetaFabric and Juniper Opens SDN, Clouds OpenDaylight.)
For industry observers looking for key differences between Cisco's Application-Centric Infrastructure strategy and Juniper's MetaFabric strategy, that perceived openness is it in a nutshell: Cisco Systems Inc. (Nasdaq: CSCO) is offering the ability to use parts of ACI with standardized elements and gear from other vendors, but saying an all-Cisco ACI is optimum, while Juniper says it's aiming for a completely open architecture and, what's more, says it can prove it.
"The Contrail controller will work with Cisco hardware, but Cisco's controller doesn't work with anyone else's," claims Mike Marcellin, senior vice president of strategy and marketing at Juniper's Platform Systems Division. Marcellin also points out that Juniper is using standard Ethernet VPN VLAN extensions in its MX Series 3D router, while routers from its rival use Cisco's own Open Transport Virtualization protocol.
SDN translation
The MX routers also have a Universal SDN Gateway capability that allows them to act as translators between different makes of SDN controllers. That capability could be crucial for customers that implement SDN in different datacenters at different times using different vendors, but then decide later that they want to connect their SDN islands.
Marcellin emphasizes that Juniper is trying to let customers build out SDN architectures without worrying about being locked into one vendor for everything. Of course, as the market leader for datacenter switching and routing infrastructure, Cisco can attempt to force the market to do things its way, while Juniper, and any other company for that matter, must be more accommodating.
MetaFabric does have a few similarities to Cisco's approach. Like Cisco, Juniper does not offer a completely virtualized solution in the mode of some SDN vendors, since it does utilize hardware -- Juniper's new QFX 5100 top-of-rack 10 Gbit/s/40 Gbit/s Ethernet switch family. Though again, Marcellin stresses the switches can be used in any datacenter fabric.
Also like Cisco, Juniper is leveraging an existing family of routers, in the form of its MX Series, though Marcellin claims enhancements such as the Universal SDN Gateway address interconnection of multiple clouds in a way few others are discussing. Both Juniper and Cisco also understand the need to support leading hypervisors, namely VMware's EXSI.
Ultimately, Juniper, like its rival, is attempting to revitalize moribund network application provisioning.
Marcellin told Light Reading this week:
You can spin up a virtualized machine in minutes. You can spin up virtualized storage in minutes. The time it takes to deploy an application on the network is less than ideal. Typically if you want to a new application on the network, you need to first open up a trouble ticket because maybe your application guys don't talk to your network guys. You may have to get new equipment, so you're talking weeks, or in the service provider space maybe a year. Ten years ago we just accepted the fact it took forever to do any of this stuff, but now everything else has evolved significantly, and the network hasn't. What happens then is that your network is not extensible. It can't grow as you get new users or as new applications come in. It's difficult to continue to use the network in the same way.
In Cisco's case, some critics have contended that revitalizing application provisioning with a hardware-centric model is an attempt to distract customers from the broader trend of datacenter virtualization.
Not all virtualized
Juniper is likely no more eager to virtualize the datacenter than Cisco. Marcellin describes the complex nature of datacenters as environments where customers have an on-premises datacenter, but also may have some assets in a managed cloud provider or hosted services provider, and other applications sitting in clouds or as part of an infrastructure-as-a-service they get from a cloud provider.
"Within all that you've got both virtualized resources and physical resources you need to use, and you need to have a simple, smart and open way of getting at all of that," he says. This is not so far off from some of the things Cisco said in its Insieme announcement, but Juniper, like any contender, is intent on offering a different world-view than the incumbent.
"With Cisco's announcement, battle lines were drawn between Cisco's datacenter model and VMware's," Marcellin says. "An all-hardware-centric model is not right because it leaves a lot of potential agility benefits on the table. But, neither is an all-virtualized, abstracted model right. Where we're sitting is a sane middle ground. There are some attributes that can be done in hardware that are absolutely required, but we want to have all the right approaches, whether someone uses Contrail or [VMware's] NSX."
— Dan O'Shea, Managing Editor, Light Reading
You May Also Like
