At their conference yesterday, Red Hat announced an expansion of (or redefinition of) its deal with eNovance that takes aim at the carrier cloud and (explicitly) the NFV space. The deal is aimed at contributing to OpenStack to make it a more suitable platform. So, yes, this is a data point in my “platformization” theme. But the questions for today are “Why?” and “Will it work?”
I ran my market model on NFV last year, and the results were interesting. While the current state of both buyer literacy and products make precision impossible, the model said that if we had an optimum realization of NFV benefits to drive an optimum deployment, we could see an additional 30,000 to 100,000 data centers generated by carrier deployments. This would dwarf the incremental opportunity for data center growth available anywhere else. Since every data center is at least a small pool of servers, software platforms, and data center switches, it’s pretty clear that this is a heck of a carrot to dangle in front of a revenue-and-profit-starved market.
I’ve said before that the Wind River people may have been the ones to validate the notion of carrier cloud and NFV as a platform opportunity, with their Carrier Grade Communications Server. Given that they’re owned by Intel they have no shortage of backing and credibility, and they’ve jumped out in front in the space. If that space is in fact the biggest new pie in the market, Red Hat can hardly ignore it. That’s the “Why?”
The corollary question is “Why now?” and the best answer to that is that the NFV ISG is winding down its first-phase work. We are getting close to the point where specifications would be released, and close to the point where early trials could be expected. Everyone knows that trials tend to mature into deployments unless the vendors behind them screw up, so you need to be in on the ground floor. Part of getting there is also PR and positioning, which get harder to develop as the field gets crowded and the easy topics are all written to death. I think it will be very difficult for vendors to gain real control of NFV and carrier cloud issues much beyond the end of this year, if they don’t have it already.
The problem for Red Hat in execution isn’t easy, though. The original NFV value proposition, reflected in the first NFV White Paper back in the fall of 2012, was an easy one for somebody like Red Hat. You take commodity servers and use them in place of expensive SDPs and appliances. Every appliance you displace offers a benefit, and the more you do the more you save. There’s no first-cost issues, no worry about integrating trial enclaves. Within a year, though, the operators themselves no longer believed in that story. They found that the complexity of NFV would almost certainly raise operations costs enough to marginalize or eliminate capex savings. You need a bigger story.
If the cloud is the logical host of NFV and carrier features and services, then it isn’t unreasonable to say that carrier cloud could evolve from something like OpenStack. OpenStack has the ability to deploy and connect stuff, and if you made it bigger and better you could make it more efficient and secure lower opex, right?
Well, probably not as much as you might think, which is where Red Hat risks going wrong. I’ve pointed out before that the current NFV target benefits of greater service agility and lower operations costs aren’t easily achieved by addressing functional islands of larger services built on legacy infrastructure. However, we’re not likely to see NFV get to the point where it drives COTS platforms into access, transport switching, routing, and optics missions. We’re darn sure not going to fork-lift a whole metro into NFV-dom to do a trial. Thus, we’re at risk in having the benefits proved for early trials not only insufficient to justify my “optimum” NFV deployment, we are risking their not funding the next step or fully justifying themselves even in the first trial.
Red Hat can make structural orchestration better. They can improve the carrier-grade quality of OpenStack, but it’s a real stretch to imagine that they can extend OpenStack beyond the cloud. I’d also point out that OpenStack management doesn’t fit well within the framework of operator OSS/BSS/NMS, and obviously it doesn’t integrate with the management of legacy elements or the automated (and hypothetical) tools used to build those new and agile services. What’s needed is a higher layer, a vision of unification of all the network technologies into a common virtualization-friendly service toolkit. eNovance doesn’t have it, Red Hat doesn’t have it.
The good news for Red Hat is that nobody else has it either, at least not fully and generally. Some are telling a story that when fully populated with products might well do the job. Alcatel-Lucent is an example, and so is Cisco and in particular HP. Overture Networks, I’ve pointed out, actually has an implementation of structural orchestration that could be made to climb up to the functional level if they (or a partner) decided to drive it there. There are enough open source tools out there to form as much as 85% of what’s needed for orchestration, and I know of at least one major vendor who has been dabbling with the stuff and seems on the fence with regard to commitment. But they’ve not committed, and so for a period of time Red Hat still could expand their vision to include the critical mass of benefits.
NFV could be a revolutionary technology, but nothing deploys by being technically revolutionary, it deploys by being benefit-revolutionary. Progress toward a goal is helpful only if it can credibly extend far enough to start funding itself with benefits, and islands of NFV aren’t going to do that if the benefits operators are looking for are systemic and not isolated.