If we really want cloud-native network service features, and optimum use of them, we should probably look at two factors beyond those that I laid out to make NFV itself more cloud-native. One is the issue of “configuration” and “parameter” control, and the other is the ever-complicated issue of address space. Again, the cloud world offers us an approach, but again it’s different from what’s been evolving in the service provider world.
When you deploy an application, especially on a virtual resource, you’ll generally need to address two setup issues. First, the deployment itself is likely to require setup of the hosting resources, including the application’s own hosting points and the hosting of external but coupled resources like databases. Second, you’ll usually need to parameterize the application (and its components) to the framework of operation you’re expecting.
The issue of address space can be considered related. Everything you deploy in a hosted environment has to be deployed in a network environment at the same time, meaning that you have to assign IP addresses to things and provide for the expected connectivity among all the elements of the applications, and with selected components and the outside world. How this addressing is done impacts not only the application and its users, but also ongoing management.
In the application software and cloud world, we seem to be converging on the container model of deployment, based at the lowest level on the Linux container capabilities, at a higher level on things like Docker or rkt, and at the highest level by orchestrators like Kubernetes or Marathon. Container systems combine the setup/configuration and addressing frameworks by defining a standard model for deployment. It’s less flexible than virtual machines, but for most users and applications the minimal loss of flexibility is offset by the operations value of a single model for hosting.
One challenge with our configuration/parameter control is version control. It’s common for both deployment configuration and component parameters to evolve as software is changed to fix problems or add features. Software evolution always requires synchrony of versions through all the components, and so version control in software goes all the way from development to deployment. The most popular mechanism for ensuring that software version control is maintained is the repository, and Git is probably the best-known tool for that.
Recently, application deployment has recognized the dependency of configuration/parameter sets with software versions, and so we’ve evolved the idea of keeping everything related to an application in a common repository—called a “single source of truth”. This creates an envelope around traditional “DevOps” practices and creates what’s being called “GitOps”.
The reason this is important is that GitOps should be the framework for configuration/parameter control for things like NFV and SDN, in part because to do otherwise would break the connection with the cloud and current application development, and in part because inventing a whole different approach wastes effort and resources. You can store repository information in a common language like YAML, and then transform from that single source to feed both parametric data to applications and configuration data to orchestrators. You can also describe your goal-state for each element, and then check your current state against it to provide operational validation.
If we were to use the GitOps approach for feature hosting, it would mean that instead of trying to frame out specific VNF descriptors, we’d lay out a structure of “class-specific” information and rely on an adapting element to derive what a VNF needs from this generalized data. That could be based on the same “derived operations” concept I explained in my earlier blog. The goal would then be to create a good general structure for describing parametric data, since we already have examples from the cloud in how to code configuration data via GitOps.
The challenge of address spaces is a bit more complicated, in part because even container systems today take a different slant on it. Containers might deploy within individual private address spaces or deploy within one massive (but still private) space, and exposed interfaces are then translated to public (VPN or Internet) spaces. You can see that how addresses are assigned is important, and that the assignment process has to be adapted to conditions as applications scale and are redeployed if something fails. Network virtualization standards have generally paid little attention to address spaces, but the cloud has devoted considerable effort to defining how they work under all conditions.
The NFV concept of “service chaining” is at least an illustration of why we have neglected address space discussions. The notion of a service chain is that you build a linear pipeline of VNFs that perform a function normally hosted in CPE. That’s fine as a mission if all you want to do is linear chains and vCPE, but it neglects a couple of major truths that we need to address.
Truth one is that IP, which is what the cloud and NFV hosting are based on, is a connectionless protocol. If you establish a service or application that consists of multiple components/features, then IP would support any sort of connection relationship you’d like among them. The notion that only a specific linear tunnel set is available is limiting, and in fact one of the best and earliest examples of VNFs that we have comes from Metaswitch and its open-source IMS implementation (Project Clearwater at the time, now Clearwater Core). Clearwater lets the component VNFs communicate as they should, as normal IP elements.
Why did we get to the “chain” concept? Part of it was just tunnel vision on vCPE, but a bigger part I think is the fact that the standards people thought too literally about VNFs. Physical devices were connected by wires, so virtual functions should be connected by virtual wires. Yes, you can build them (tunnels of some sort) in IP networks, but would you want to do that when natural IP communications works directly?
Tunnel-focus elevates network thinking to the tunnel level, and since you can in theory tunnel over almost anything, that means that it’s easy to forget what’s below, including address spaces. If you want to deploy applications, though, you need to understand what’s addressed and how, and how addresses either create or limit open connectivity. That’s a lesson that needs to be learned.
I’d argue that these two points are actually easier to address in a rethinking of NFV than the points I’d made in my earlier blog, but it wouldn’t do a lot of good to address them without having dealt with those more complex issues. If you are really going to be cloud-native, you need to have framed your notion of NFV in the cloud from Day One. Getting to that from where we are today is possible, but as these two blog points show, the cloud advances in its own relentless flow and the longer NFV diverges, the greater the gulf that has to be bridged. We’re already at the point where it’s going to be difficult; shortly it’s not going to be possible.
That might not be the worst outcome. Little that’s done in NFV today is really optimum, even if we can diddle things to make it at least workable. Cloud architects doing NFV would have done it differently (as my own work demonstrated), and it’s still possible to meet all the goals of the 2012 Call for Action using cloud tools alone. I think we’re going to see some try that in 2019.