Sometimes you look for the wrong monsters under the bed. IBM made an announcement today demonstrating that’s true in networking, and in two dimensions. They came out with specific support for Network Functions Virtualization and they announced a successful partnership (with Connectem) to field virtualized mobile core infrastructure for Optus in Australia. This shows that 1) a big computer vendor recognizes the potential for NFV and 2) once you virtualize functions they can be provided by a host of software developers.
Everyone is looking at SDN as being the boogie man in network equipment sales, but my numbers are showing that while SDN will be strong in the data center over time, and it can also play a major role in the metro network, SDN’s potential is limited by lack of central-control mechanisms. There will be a respectable SDN market, but it’s not going to kill the network vendors’ profits or sales.
NFV could be another matter completely. First, as IBM points out, shifting functions out of purpose-built hardware into software where they can be deployed quickly and instantiated based on load requirements makes networks more flexible. Substituting servers for custom devices makes it cheaper. And if software types see the potential for developing new NFV-based features to sell as service components (I blogged on this yesterday) then we could finally see a framework where network operators get a chance to raise revenues and not just cut costs. That’s what IBM sees, clearly.
But for all the potential here, IBM is still shooting behind the duck. You can’t advance a strategy by holding your partner’s hat. IBM needs an architecture for NFV that their partners would build to, because absent the architecture NFV ends up being islands of functionality lost in a disconnected cloud ocean. And guess what? IBM’s arch-rival Cisco knows that darn straight well. Another problem IBM has is that if there was ever something that cried out for centrally controlled OpenFlow-flavored SDN, it’s metro mobile. You have everything in mobile core signaling that you need to manage cell-hopping and addressing and backhaul and priority-and-profit-based offload in a central way, but there is no specific SDN link here.
The IBM angle opens another topic, which is IBM’s partner Juniper. A lot of Juniper people go to bed at night praying IBM will buy them. Juniper was recently reported as unsuccessfully trying to sell off its enterprise (security) business so it could focus on the service provider space. The current story is that it wants to raise some capital in a private placement of stock to reignite enterprise. Well, the service provider space is a shrinking target unless you count servers and software into it. IBM has those already. Network equipment is what’s shrinking, so IBM is supposed to buy Juniper to get in on the decline? Show me how that’s smart.
IBM needs to have an NFV architecture not just partners who have applications that look NFV-ish. Cisco needs the same thing, and their weakness (which IBM can exploit) is that their slant on NFV isn’t going to threaten current equipment, which means it’s basically NFV neutered. HP has both networks and IT and perhaps the best position from which to launch a true NFV/SDN/cloud story, but they’ve not launched it. Juniper doesn’t have NFV at all, or at least they want to call their clearest NFV advances “SDN” instead. If IBM wants to stave off Cisco, they need real NFV. If Cisco wants to attack IBM in the service-provider space, they need real NFV. If Juniper wants an enterprise strategy they will have buy an NFV/cloud player, and then doing something a lot more sensible with it than they’ve done with their assets so far. Then all these guys have to tie NFV to SDN to complete the circle.
Which sets the marching orders for some other players. The TMF has got to forget the notion of OSS/BSS in an NFV cloud and start talking DevOps or they’re defining a backhoe to weed a patio pot. The ONF has got to start thinking about the real mission of central networking and the standards and protocols that would support that mission, not just about shoehorning OpenFlow into every real application, whether it fits or not. The NFV people have to recognize they are building a platform-as-a-service definition of what a network application looks like in the cloud, and get to work on that task. It’s software…programming. How many abstractions can dance on the head of a pin? Any number, but nobody will notice. We need real stuff here, from vendors and from standards bodies, and the things we need are as clear as the nose on your face, as the saying goes.