Did Juniper Sing MetaFabric Pretty Enough?

Juniper may not have wowed the Street with its last earnings call, but with some of its rivals definitely closer to the drain, earnings-wise, and it’s clear Juniper still has assets in play.  The latest Juniper move to leverage those assets is a new slant on the data center of the future, called “MetaFabric”.  Unlike Juniper’s (dare I say, “ill-fated”) QFabric, MetaFabric is an open architecture supported by Juniper products.  I like it, and given that the data center isn’t exactly a Juniper lake, it’s a smart move, but not one without risks.

MetaFabric is a good hardware strategy but not an exceptional one.  What probably differentiates it is its goal of higher-level openness, the support for a variety of cloud and IT environments and the specific embracing of VMware, a player who’s been on the outs with Cisco.  I think it’s clear that MetaFabric is aimed at Cisco, and at invigorating the old Juniper strategy of hitting Cisco on lack of openness.  However, the openness angle makes it hard to differentiate and puts more pressure on Juniper to establish some high-level value proposition.

The stakes here are high.  Networking is becoming the poor stepchild to IT in both the enterprise and service provider spaces, and that shift is largely because you can’t create profitable services based only on pushing bits around.  For network equipment vendors like Juniper, the problem is that pushing bits is what you do, what your incumbent positions are based on.  For a bit-pusher to enter an era where services are built higher up, it makes sense to focus on the place where those services couple to the network—the data center.  Not to mention the fact that for six years now my surveys have shown that data center network trends drive network spending in the enterprise.  Juniper needs help there too, based on its last quarterly call.

Juniper’s first challenge is overcoming a truly alarming loss of strategic influence.  Among service providers, Juniper has lost more influence since 2010 than any other network vendor.  In the enterprise space their losses lead all other network vendors too; only HP has fallen further, and their problems can be attributed to their management shifts.  In the enterprise, Juniper’s data center evolution strategic influence loss is the largest of any vendor’s, primarily because of their muddy QFabric launch.  Historically, what it takes to make something like this right is some impeccable positioning, something Juniper hasn’t been able to muster.  Can they do it now?  The potential is there, I think, because there are market trends that could be leveraged.

In cloud computing of any sort, the biggest difference in data center networking arises from the growth of horizontal traffic.  Any time you compose applications from components you generate horizontal flows and that stresses normal data center architectures that are designed to deliver application silos vertically to users.  Even cloud multi-tenancy doesn’t change this, but componentization does and componentization is the critical element in supporting point-of-activity empowerment, which is likely the largest driver of enterprise change in the rest of this decade.  More productivity, more benefits.  More benefits, more spending to secure them.

On the operator side, it’s NFV that’s driving the bus.  A fully optimized NFV would create more new operator data centers than new data centers from all other sources combined.  In fact, it would make network operators the largest single vertical in data center deployment terms.  NFV more than even the cloud demands very high performance within its data center, and nearly all NFV traffic is horizontal.  Juniper, who is hosting the NFV event that starts literally today, has a chance to leverage NFV into a place in the largest set of data center orders the world has ever known.

There’s a lot of ground for Juniper to plow, but they’re having problems getting hitched up.  Juniper has up to now resisted even the notion of naming something “NFV”.  I had a useless conversation with a top Juniper exec who took exception to my characterizing their service chaining as an “NFV” application when they wanted to say it was SDN.  They need to start thinking of it as NFV now, if they’ve not learned that already.  But if they have, Juniper’s white paper on MetaFabric misses the mark.  They gloss over the key issues that are driving horizontal traffic to focus on automation and operationalization, which would be great topics if you targeted them at NFV where such things are literally the keys to the kingdom.  Juniper’s paper never mentions NFV at all.  It never mentions horizontal traffic, in fact.

The most telling point Juniper makes about MetaFabric is buried in a VMware-specific paper.  There, they talk about the need to connect physical and virtual networks, and while they open the topic in a pedestrian way there’s a lot of substance in what Juniper can offer here.  I’ve become convinced that the SDN world of the future is bicameral, with a higher virtual layer that’s very agile and application-specific linked to a physical network that’s policy-driven.  The Juniper Contrail approach is well suited to that story (so is Alcatel-Lucent’s Nuage) and you can make a strong argument for the story that the evolution of the data center will drive this new SDN vision all the way to the edge of the network.

There’s a good metro story here too, a story that could address the hole Juniper’s left in its strategy after killing its mobile architecture recently.  Operators want virtual EPC.  Data centers host virtual EPC.  Juniper is doing MetaFabric for data centers.  See a connection here?  I’d sure like that connection to be made strongly, but it isn’t.

So here’s the net.  I think NFV is the movement that’s most directly driving data center evolution, even for enterprises, because it’s pulling the cloud, SDN, and NFV goals into a single package and wrapping it in a strong operational story (one Juniper wants to tell).  Juniper needs to board the NFV bus if they want MetaFabric to succeed.

Leave a Reply