Zero to ONAP in Seven Minutes
The concept of Network Function Virtualization (NFV), as simple as it is, brings with it much complexity. In some respects NFV is simply taking virtualization – a technology most IT organizations are quite familiar with, and indeed is a commodity, – and applying it to telecommunications systems.
For various reasons, NFV has become much more than simple virtualization. In combination with the drive towards 5G it has come to represent a sea change in how telecommunications companies create and operate services. The most common discussed requirements of this paradigm shift are automation and agility.
Undeniably, automation and agility come at the price of complexity. To achieve both automation and agility we require complex, and some would say complicated, infrastructure capable of abstracting away underlying resources such as compute, storage, and networking with Application Programming Interfaces (APIs).
Technologies like Infrastructure-as-a-Service (IaaS, eg. OpenStack) and Software Defined Networking (SDN), among others, provide these necessary abstractions and APIs, but something needs to talk to them…something needs to manage and orchestrate them.
Enter the MANO
The Management and Orchestration (MANO) layer is a complex and evolving component of ETSI defined NFV. Recently several open source MANO systems, such as ECOMP, OPEN-O, and OSM have sprung into existence, and, like any startup or other new organization, sometimes they succeed, sometimes they fail, and other times they are acquired or merge with competitors.
ONAP, the Open Network Automation Platform, is the combination of two of the aforementioned projects: ECOMP and OPEN-O. The new project, ONAP, falls under the purview of the Linux Foundation and is supported by a vast membership representing a consortium of many major telecommunications companies, vendors, and open source developers.
ONAP Deployment
Recently ONAP celebrated the Amsterdam release of ONAP, and in this blog post we’ll show a quick demonstration of deploying a relatively complex ONAP system into Kubernetes using the ONAP Operations Manager (OOM). They key point of this demo is the fact that this deployment, or Day 1, can complete in under seven minutes.
Below you can watch a video that shows a deployment of ONAP using OOM. The video has been sped up in parts, but the actual elapsed time of the deployment is only 383 seconds.
We also have a video of the WeaveScope view of the deployment for a more graphical depiction of the creation and connection of the various ONAP components in Kubernetes.
Day 1 in Seven Minutes
Certainly a few major requirements exist for this demo, such as having a Kubernetes cluster to deploy to, but what we’ve shown is that on Day 1 ONAP can be deployed in less than seven minutes. When the deployment phase of any complex system is simplified and abstracted it can become commoditized and available to a larger user base.
However, once any system has been deployed it needs to be maintained and operated over time, commonly known as Day 2–a part of the life-cycle of any complex system that tends to be the most challenging. Fortunately, as ONAP, OOM, and Kubernetes mature we should find that Day 2 becomes closer in terms of cost to Day 1.