What makes orchestration so hard? Another Light Reading piece on NFV asks whether open-source is the right choice for NFV orchestration. It’s a good question, but only part of the bigger question, which is how we’d define “rightness” to begin with. It’s pretty obvious that there are multiple visions of orchestration, both within the NFV community and between that community and cloud computing. How the heck did we get so far astray on even the basics, when orchestration is so critical?
The first issue was taking a limited-scope, bottom-up, view of the problem. The NFV ISG, from the first, saw their task as being one of creating a simple framework that substituted a collection of virtual network functions (VNFs) for a traditional network device, or physical network function (PNF). That process, they perceived, would involve things like chaining a succession of VNFs together, hence the focus on “service chaining”. To the ISG, “orchestration” and “management” were directed first at the deployment of the VNFs that made up the virtual device, and second to manage the things that happen within the VNFs that don’t directly relate to the management of the function, which they presumed would be handled the old way, via EMS/NMS/SMS and OSS/BSS processes.
Most of the work on NFV orchestration has tracked this approach, which means that the NFV work really only addressed the incremental orchestration mission of virtual functions, not the broader mission of orchestrating network services that might or might not contain VNFs. This was fine when it was presumed that NFV could be justified by the capex savings associated with device replacement by virtual functions, but not when opex efficiency and service agility were included as benefits. That opex and agility were essential was recognized by the end of 2013, but the scope of NFV orchestration wasn’t broadened.
The second issue, which I touched on in yesterday’s blog, was ignoring the cloud. Perhaps it would be fairer to say that the early work focused on the cloud for only one component of the architecture, a component that lived below orchestration. At the time of the early work on orchestration within the ISG, we already had a cloud evolution of orchestration. Kubernetes, probably the best known of the “orchestrators” for the cloud, was launched 15 years ago as a series of Google projects and open-sourced as Kubernetes in 2014.
The cloud principle of orchestration, embodied not only in Kubernetes but in other tools, including DevOps tools, is that lifecycle management is an overlay, a layer that lives on top of a set of resource abstractions and that operates below a series of “goals” or “end-states” that drive the process. The orchestration layer takes definitions of those end-states (which represent applications or services) and applies them to the resource abstractions, which in turn are mapped to the real resources. This differs from the NFV approach, which focuses orchestration only on that last-stage mapping.
The third issue with NFV orchestration was building toward the “right” solution from the wrong baseline. AT&T’s ECOMP is a massive positive step in terms of functionality, but what ECOMP (now absorbed into ONAP) did was to create a kind of middle-management layer that was still designed to overlay the original NFV orchestration concept. This approach turned ONAP into what’s essentially an extension of the management system, not an orchestrator. It’s not abstraction-based, model-based, which is what the cloud would have mandated.
The same bend toward the ISG orchestration approach has impacted the vendor orchestration approaches, for the most part. There are a few vendors who have a model-driven orchestration strategy, but most of these are still trying to link their approach to the NFV ISG orchestration model, and none that I’ve seen are based on the basic cloud orchestration standard, Kubernetes. Does that mean that Kubernetes isn’t suitable? More likely it means that Kubernetes and other orchestrators could play a role in a higher-level master orchestration approach, but if we started our processes by accepting the NFV model of orchestration, where would Kubernetes fit? It goes back to the first problem. We didn’t think of the future of NFV orchestration, or more broadly of service orchestration and lifecycle management, as a model-driven approach with each element in the model being an intent model, free to decompose what it contains in whatever way seems optimum.
This relates to the question that the Light Reading piece asks, but perhaps not the way it might appear. The fact is that we don’t have the right model for orchestration today, period. The question then isn’t whether open-source or proprietary orchestration is right, because neither is. The question is whether open-source orchestration can get to the right answer faster than proprietary approaches could, and that’s a tough question to answer.
I don’t believe that ONAP will evolve to the right answer. I’ve had some concerns about it, temporarily relieved when the ONAP people told me that they were going to be releasing model-based orchestration. The problem is that they’ve not done that, and it’s clear to me from reviewing the material and talking to operators involved in ONAP that they’re not able to pivot the architecture of ONAP to the right approach, the approach that the cloud has already proven out.
I also believe that the ETSI Zero-Touch Automation (ZTA) stuff is going to miss the boat. First, it’s jumping off explicitly from the NFV ISG stuff. Second, these ETSI ISG processes have proven to take forever and follow the traditional standards-group model, which is unlikely to result in anything useful in any reasonable period of time. That means that the answer to the question “Is open-source the right approach to NFV orchestration” is “No.” We don’t have it, and we don’t have a convincing framework to achieve it.
That might also be true of proprietary stuff, of course, but a proprietary initiative to solve the problem of orchestration has two advantages. First, there’s no competing directions to harmonize, as there always is with open source. Second, there’s the powerful profit motive. Somebody who gets this right can hope to make a lot of money selling it. That’s why I’ve been saying that I think it’s going to be up to vendors to solve the orchestration problem. Some have made progress in doing that already, and I expect that by the end of next year we’ll see some real NFV and service orchestration offerings available.