“E Pluribus Unum” is the motto found on US coins and it means “From Many, One”. Will that work for NFV? We may have to find out, because it seems that instead of converging on specifications NFV is flying off in a bunch of different directions. Is that appearance reality, and if so what’s going to happen?
It is true that there’s more difference developing in NFV than commonality. Just the fact that we have two open-source orchestration initiatives is interesting enough, but we also have the AT&T ECOMP project, and today HPE, Anuta Networks and Logicalis announced a partnership deal that will link HPE NFV Infrastructure with Anuta orchestration. HPE, you may recall, has its own orchestration product, and in fact it’s one of the six that’s actually complete. We also have OPNFV, which might end up doing yet another open-source implementation.
There is one ETSI specification for NFV, and at the detail level it’s fair to say that it’s been weighed and found wanting. The ETSI spec issue is the core of the explosion of implementations and approaches. If we had a spec that everyone agreed could make the business case at least close to optimally, I think it would have converged a lot of stuff on a single approach. Since it doesn’t what we’re seeing is a combination of competitive opportunism and special-interest focusing of efforts.
You can’t differentiate in a service provider market by abandoning an accepted standard, but if there are major omissions then those will attract differences in approach simply to help sales people make their own strategy stand out. That’s why, with six implementations of NFV that can make the business case, we have minimal compatibility among them. Since we’ve now embarked on competitive approaches to the NFV problem, even harmony at the spec level wouldn’t be likely to drive convergence in approaches. And we’re not going to get specs that will generate harmony any time in the next year.
The target factor is more complicated and more pervasive. We do not, at this point, have anybody who’s presenting operators with an NFV story that would justify wholesale adoption of NFV. Even the vendors who can make the business case for NFV aren’t doing that on a broad scale because such a deal would take a lot of sales cycles, during which nobody would make quota. As in all new technologies, though, there are places where NFV can be made to fit more easily. Not only does focusing on one of these things shorten the selling cycle for those vendors who could do the whole thing, it admits a bunch of other vendors who can’t do it all but who can cobble a service-specific story together.
Given the number of issues we’ve already uncovered in NFV with integration at the infrastructure, function on-boarding, and management levels, it might seem that this explosion of service-specific NFV silos would only add to the angst. Actually it might help things.
NFV has from the first been a multi-level structure built from abstractions representing service features or behaviors, whether vendors have optimized that principle in implementation or not. This structural model predates NFV, going back to the days of IPsphere and the TMF’s Service Delivery Framework, and even its SID modeling. Each of the abstractions is essentially a black box, opaque.
One property of a black-box abstraction it that it can contain a bunch of other abstractions. That means that a “service” created by one vendor’s NFV solution would contain within it a lot of low-level models that eventually ended up with stuff that represents deployment of resources. From the top, or the outside, it would still look like a single block in a diagram. It should be possible, then, to represent the product of silo deployments in a way that allows it to be incorporated as an element in another silo. Yes, you’d have to jiggle the APIs or data formats, perhaps, but it is possible.
This issue is the one I’ve called “federation” in past blogs, and it could go a long way toward not only eliminating the lock-ins and other optimality issues associated with silo deployment of NFV, it could also help make the broad NFV business case. Best of all, it could encourage vendors to think more in terms of integration at a level where the results could actually be applied.
We are not going to fix the sins of omission in the NFV specification process in time to do much good. We are not going to be able to harmonize the integration of VNFs or even the portability of resources with the current open-source activities either, at least not in time to address operator concerns about profit per bit. We are going to continue to have low-apple, service-confined, NFV deployments because that’s the only way to balance risk and reward at this point. We need to focus elsewhere.
The NFV ISG could prioritize effective “service object federation” right now. The various open-source groups could do likewise. A third body could undertake the task. Any way it happens, having a way to link the service-based silos and implementation enclaves that we’re building would help to generate a broad solution. The problem is that none of these ways are going to move fast enough.
For vendors, there would be an obvious advantage that accrues to those who could absorb other silo objects into their own service models. That benefit could be the thing that moves vendors to do more on their own here. Make no mistake; nothing is going to save NFV’s ability to drive better profit per bit except vendor-driven solutions. Which means that we can only build more silos. Which means we have to address silo-binding right now before we collapse our emerging NFV house of cards.
Any intent-modeled structure is self-federating, meaning that since the stuff inside a model element is invisible, it could just as easily have been created by some other service group or even another operator. Operators who have been pushing for intent-modeled NFV could, if they push with a bit more emphasis on federation, force vendors to accommodate that silo-binding mission without much additional effort.
Of course, operators themselves have had tunnel vision with NFV. Vendors have worried more about protecting any advantage they gain from early participation in silo-building deployments than building the broad business case by creating an NFV ecosystem. Some, I think, are starting to realize that there’s an issue here, and I hope these players will lead the charge to change.