The Linux Basis’s Open Community Automation Platform (ONAP) is nicely into its third 6-month launch (Casablanca got here out in Dec ’18), and whereas the mission has developed because it’s first launch, there’s nonetheless some confusion about what it’s and the way it’s architected. This blogs takes a more in-depth have a look at ONAP, under-the-hood, to make clear the way it works.
To start out, it is very important think about what performance ONAP contains. I name ONAP a MANO++, the place ONAP contains the NFVO and VNFM layers as described by ETSI, however goes past by together with service assurance/automation and a unified design device. ONAP doesn’t embrace the NFVI/VIM or the NFV cloud layer. In different phrases, ONAP doesn’t actually care whether or not the NFV cloud is OpenStack, Kubernetes or Microsoft Azure. Nor does ONAP embrace VNFs. VNFs come from third-party firms or open supply initiatives however have VNF tips and onboarding SDKs that ease the deployment. In different phrases, ONAP is a modular platform for full Community Automation.
OK, finish of background. On to 4 themes:
Mannequin-driven is a central tenet of ONAP. If something, one may complain about there being an excessive amount of model-driven pondering however not too little! There are fashions for:
Community service descriptor
Closed-loop automation template descriptor
APP-C/SDN-C directed graphs
The large bang (simply kidding)
So on and so forth
The important thing concept of a mannequin pushed strategy is to allow non-programmers to vary the habits of the platform with ease. And ONAP embraces this paradigm totally.
ONAP goes by nice pains of making a hierarchy and offering the very best degree of abstraction to the OSS/BSS layers to assist each a cloud-based and device-based networking strategy. The under present a few examples.
Service Orchestration & LCM (the left-hand aspect merchandise feeds into the right-hand aspect merchandise):
VF ⇛ Module ⇛ VNF ⇛ Community/SDN service ⇛ E2E community service ⇛ Product (future) ⇛ Provide (future)
Analytics Microservices & Insurance policies ⇛ Closed Loop Templates
With upcoming MEC purposes, the million greenback query is, will ONAP orchestrate MEC purposes as nicely? That is to be decided, but when this occurs, ONAP will likely be even farther from device-orientation than it already is.
ONAP Casablanca is transferring in direction of an emphasis on cloud native; so what does that imply for digital community capabilities (VNFs), or ONAP’s capacity to supply an operational layer for NFV? To interrupt it down extra particularly:
Can VNFs be cloud native? Sure! The truth is they are often, and ONAP extremely encourages, I daresay, insists upon it (see ONAP VNF Growth necessities right here). Cloud-native or containerized community capabilities (CNFs) are simply across the nook and they are going to be totally supported by ONAP (once we say VNF, we embrace CNFs in that dialogue).
ONAP documentation contains references to VNFs and PNFs – does that imply there isn’t a room for CNFs? ONAP refers to VNFs and PNFs since they represent larger degree providers. This is able to be tantamount to saying that if AWS makes use of the phrases VM or container, they have to be written off as outmoded. Furthermore, new providers equivalent to 5G are anticipated to be constructed out of bodily community capabilities (PNFs) — for efficiency causes — and VNFs. Subsequently, ONAP anticipates orchestrating and managing the lifecycle of PNFs.
Is the truth that VNFs will not be all the time written in a cloud-native method imply that ONAP has been mis-architected? It’s true that a lot of VNFs are VNFs-in-name-only (i.e. PNFs which have been virtualized, however not a lot else); nevertheless, that is orthogonal to ONAP. As talked about above, ONAP doesn’t embrace VNFs.
LACK OF INNOVATION
We’ve additionally heard solutions that ONAP lacks innovation. For instance, there have been questions across the sorts of clouds supported by ONAP along with OpenStack and totally different NFVI compute cases along with digital machines. The truth is, ONAP supplies super flexibility in these areas:
Completely different clouds — There are two ranges at which we are able to focus on clouds. First, clouds that ONAP can run on, and second clouds that ONAP can orchestrate VNFs onto. Since ONAP is already containerized and managed utilizing Kubernetes, the primary matter is moot. ONAP can already run on any cloud that helps k8s (which is each cloud on the market). For the second use case, the ONAP Casablanca launch has experimental assist for Kubernetes and Microsoft Azure. There isn’t any cause so imagine that this new cloud varieties like AWS Outpost and so forth. can’t be supported.
Completely different compute varieties — Presently, ONAP instantiates VNFs which can be packaged as VMs. With this, ONAP already helps unikernels (i.e. ridiculously small VMs) ought to a VNF vendor select to bundle their VNF as a unikernel. Furthermore, ONAP is engaged on full K8s assist that may permit container and Kata Container primarily based VNFs. The one compute kind that I believe isn’t on the roadmap is function-as-a-service (aka serverless). However with an NFV use case I don’t see the necessity to assist this compute kind. Possibly if/when ONAP helps MEC utility orchestration, it should want to take action. I don’t view this as a showstopper. When the time comes, I’m certain the ONAP neighborhood will determine easy methods to assist function-as-a-service — it is not that arduous of an issue.
Completely different controllers — By means of the usage of message bus strategy, ONAP has a set of controllers optimized for layers of SDN/NFV (bodily, digital, utility).
In abstract, it’s all the time essential to be sure to are conscious of ONAP’s capacity to assist a mannequin pushed, service oriented, cloud native, transformative future. Hopefully this weblog clarifies a few of these factors.
This text was written by Amar Kapadia and was beforehand printed at Aarna Networks.