Ever hear of the game “Truth or Lie?” We’ll soften the concept a bit by calling this “Truth or Myth” with a focus on transformation for network operators, but the essential idea is the same. There are stories about what’s needed for transformation that are myth, and other stories not being told despite the fact that they’re true. So let’s get started.
Truth or myth: standard APIs are critical to transformation. APIs are link points between software elements, and organizations ranging from ETSI to the Linux Foundation and ONAP have focused on defining APIs as a pathway to ensuring interoperability among components and the creation of an open framework for the software. Is this as essential as we seem to think?
The problem with standard APIs in lifecycle management software is that lifecycle management software shouldn’t be built as a series of connected components in the first place. Management is inherently an event-driven process. When we talk about connected components, we’re talking about a software application that has a linear workflow, where information moves in an orderly way from component to component. This is true of transaction processing systems, but it can’t be true of operations management systems.
Imagine that we get a command from a service order system to spin up a service under a given order number. That might sound like a transaction, but consider this: suppose the service is already in the process of being spun up. That’s an error, so you need to check to see if the state of the service matches the command, right? OK, but can’t we still do this as a linked workflow? No, because as we start to spin up the service, we’re going to start deploying and connecting pieces, and each of these tasks could complete properly or end in an error.
How does our linear system handle the fact that while one command (our spin-up order command) is moving through the system, other signals about completion of early steps are still going on? How do we even know when all the pieces are fully operational and the service can go live? In linear systems, we’d always be testing the status of other pieces of the order, and that means the software would have to know what and where those pieces were. That makes the software specific to the service structure, and we can’t have that.
Verdict: Myth.
OK, how about this one. Truth or Myth: service components like VNFs need a standard descriptor to hold their parameters because otherwise they aren’t interchangeable. In NFV, we have a VNF Descriptor that describes the deployment of a VNF and defines the structure of the information needed to parameterize it. We’re hearing all the time that one big problem with VNFs today is that they don’t have the same parameter needs, and so every onboarding of a VNF is an exercise in transforming their parameters to the VNFD. Is that really a problem?
Well, look at the cloud and containers and the notion of “GitOps” for the answer. In container deployments in the cloud, a software component image is packaged with the associated parameters, which are stored in a repository. A “unit of deployment” is the component plus its parameters, and that’s deployed as a unit by the container system (Kubernetes, usually). The needed information is simply pulled from the repository, which is now the “single source of truth” on the component in detail and on the service overall.
The only thing we have to deal with in supporting multiple implementations of a given service function like a VNF is the notion of an intent model that harmonizes its external parameters and features. In other words, we have to make all the things look the same from the outside in, not make them the same in all their parameterizations. To do this, you don’t need (and in fact can’t use) a descriptor, you need a class-and-inheritance model. All firewalls are members of the “Firewall” class, and all must harmonize to the same visible parameter set. But is that a burden? Nope; we transform one data model to another in programming all the time. Descriptors are artifacts of “old-think”.
Verdict: Myth.
Next, Truth or Myth: Network services based in software can’t be based on cloud principles alone, so we need to define new standards for them. The original mandate of the NFV ISG was to identify specifications that would serve to deploy and manage service components, not write new ones. Yet we’ve spent five years or more writing specifications. Obviously that meant that there were no standards that could serve to deploy and manage service components, right?
A deployed component, in the sense of a VNF, is simply a piece of software. The cloud standards for deploying it are the same as for any other piece of software. From the first, back in 2013 when the work of the NFV ISG started, there were multiple standards that could have defined the deployment process, and in fact the ISG’s work has always been based on OpenStack at the “bottom” of the mapping of resources to VNFs. Since then, advances in the cloud have continued and now offer us an even better approach to deployment. But doesn’t that mean what whatever we did back in 2013 would have been obsolete today had we gravitated totally to a cloud model?
No, it doesn’t. Generally, cloud evolution is optional and not mandatory, and people pick a new concept because it offers overall benefits to offset any migration efforts needed. If you don’t like the trade, you don’t change your approach. The fact that the cloud is evolving means that people do like what’s happening, and operators would have liked it too, had they done the right thing up front.
Verdict: Myth.
OK, no truths here? Try this: Truth or Myth: NFV is not living up to its promise. NFV will totally transform networks, except that it isn’t happening. Is the problem of NFV simply a startup problem, a case of working through other issues to refine the approach before the inevitable explosion of adoption, or is there a fundamental problem?
This one is Truth, and a big part of the reason is the fact that the operators, or at least the CTO organizations where standards work is done, accepted the other myths as truth. Another big part is that from the very first, NFV was about reducing capex by substituting commercial server hosting of VNFs for custom network appliances. That simply didn’t save enough money, and furthermore the cost (the opex) associated with deployment and lifecycle management of virtual functions more than offset the savings on equipment.
NFV is never going to be what was planned, period. It targets stuff like virtual CPE where the business case is minimal for the services that are appropriate, and non-existent for most services. It excludes the operations issues that alone could have justified NFV. Even doing NFV right wouldn’t have produced the sweeping benefits many had hoped for, but it would have prepared operators for the right story, which was (and is) carrier cloud.
The sad thing here is that the zero-touch automation stuff, including ETSI ONAP, have gone exactly the same place as NFV. We’re uniting things like ONAP and OSM in an effort to coordinate standards and open-source, but neither ONAP nor OSM is the right approach to start with. Two wrongs make a greater wrong, not a right, and that’s truth, the ultimate one.