From almost the first meeting of the NFV Industry Specification Group, there’s been a tension between NFV and the cloud. Virtual Network Functions (VNFs) are almost indistinguishable from application components in the cloud, and so platforms like OpenStack or Docker and tools like vSwitches and DevOps could all be considered as elements of NFV implementation. Actually, “should be considered” is a more appropriate phrase because it makes no sense to assume that you’d duplicate most of the capabilities of the cloud for NFV.
What doesn’t get duplicated, or shouldn’t? Our vision of NFV is increasingly one of a multi-layer modeled structure where the top is service-specialized and the bottom is infrastructure-generalized. The cloud is a hosting model at the bottom layer, but current virtual CPE trends show that virtual functions can be hosted without the cloud. Our vision of the cloud is also increasingly multi-layer, with virtualization or cloud stack platforms at the bottom, an “Infrastructure-as-Code” or IaC model between, and DevOps tools above. You’d think the first step in harmonizing the cloud and NFV would be to solidify the models and their relationships. That’s not yet happening.
In a rough sense, the cloud’s IaC concept corresponds with NFV’s notion of a Virtual Infrastructure Manager. Either of them would wrap around the underlying platforms and management tools needed to deploy/connect stuff. The cloud vision of IaC, which includes the specific notion of “events” that trigger higher-layer processes based on resource conditions, is more advanced in my view. Most significantly, it’s advanced in that it presumes that IaC has to work with what the platform does, and the NFV ISG seems to think that it needs to do a gap analysis on OpenStack (for example) and submit changes. That opens the possibility of long delays in coordinating implementations, and also raises the question of whether many of the NFV-related features belongs in a general cloud implementation.
Which raises the question of the next layer, because if you don’t have something in the bottom you probably want to look at putting it a layer above. In the cloud, DevOps is a broad and modular approach to deployment that could (and in most cases, does) offer a range of options from deploying a whole system of applications to deploying a single component. In NFV, you have Management and Orchestration (MANO) and the Virtual Network Function Manager (VNFM), with the first (apparently) deploying stuff and the second (apparently) doing lifecycle management. However, these are subservient to a model of a service that presumably exists higher up, unlike the cloud which makes the DevOps layer extensible as high as you’d like.
Operators like AT&T, Orange, Telefonica, and Verizon have been working through their own models for service-building that start up with operations software (OSS/BSS) and extend down to touch SDN, NFV, and legacy infrastructure. Even here, though, they seem unwilling or unable to define something DevOps-ish as a uniform higher-layer approach. TOSCA, as a data model, would clearly be suitable and is already gaining favor among vendors too, but some (Cisco included) have orchestration tools that fit into a lower-level model (based on YANG) and don’t really have a clearly defined higher-level tie-in.
One of the impacts of the confusion here is a lack of a convincing service-wide operations automation strategy. I’ve blogged about this recently, so I won’t repeat the points here except to say that without that strategy you can’t realize any of the NFV benefits and you can’t even insure that NFV itself could be operationalized with enough efficiency and accuracy to make it practical. Another impact is an inconsistent, often impractical, and sometimes entirely omitted integration model. The whole cloud DevOps/IaC concept was built to let applications/components deploy on generalized infrastructure. Without agreeing to adopt this model for NFV, or to replace it with something equally capable, you have no broad framework for harmonizing different implementations of either network functions or infrastructure elements, which puts everything in the professional-services boat.
Interface standards like the ones described in the NFV documents aren’t enough to assure interoperability or openness. Software is different from hardware, and the most important thing in software is not how the elements connect (which can often be adapted simply with some stubs of code) but how the elements interrelate. That’s what describes the features and functions, which is the primary way in which an open approach can be architected. We need this high-level model.
Another reason we need the model is that since it makes no sense to assume that we’d duplicate cloud efforts in NFV, we need to understand where NFV requirements are introduced and how they’re realized. Much of that the ISG is working on relates to the description of parameters. What functionality, exactly, is expected to use them? Do we want OpenStack to check for whether a given VNF can be deployed on a given host, or do we want some DevOps-like capability to decide which host to put something on given any exclusionary requirements? If we wait till we try to deploy something to find out it doesn’t go there, deployment becomes a series of trial-and-error activities.
Both the “declarative” (Puppet-like) and “imperative” (Chef-like) models of DevOps allow for the creation of modular elements that can be built upward to create a larger structure. Both also have IaC features, and both allow for community development of either IaC or application/VNF elements and the sharing of these among vendors and users. This NFV could ride a lot of this process and get to a useful state a lot faster.
It could also get to the cloud state, which may be the most critical point of all. The difference between a VNF and an application component is minimal, as I’ve noted above. If operators want to offer features like facility monitoring, is that feature a “VNF” or a cloud application? Wouldn’t it make sense to assume that “carrier cloud” was the goal, and not that the goal was NFV? And IoT is just one of several examples of things that would logically blur the boundary between NFV and the cloud even further.
The good news here is that operators are framing NFV in a logical and cloud-like way in their own architectures. It’s possible that these initiatives will eventually drive that approach through the open-source NFV initiatives, but the operator approaches themselves are the real drivers for change. NFV is not going to deploy if it has to re-invent every wheel, and those who are expected to deploy it know that better than anyone.