The 6th release of ONAP, Frankfurt, got released today. Four things jump out at me:
The biggest danger for an early stage open source project is whether it reaches escape velocity before the novelty wears off. For ONAP, this has frankly been something I have been worried about the most. The current release has been quite encouraging on this front. This table shows the commercial activity around all or a subset of ONAP projects:
Customers in production/ pre-production7Customers in PoC/Pilot7Customers Contributing5Vendors with a Pure-Play Product3 (including Aarna)Vendors Using Parts of ONAP for a Product7Vendors Providing ONAP Services7
Are we at escape velocity with ONAP? You tell me :).
A related point, Bell’s use of ONAP has thus far been shrouded in mystery. As of today this has changed. Now you can now find out exactly what Bell is using ONAP for, how they put it into production, and what value they are getting in this recent customer case study by LF. More in perhaps a subsequent blog.
The Orange OPNFV crew took over the ONAP Integration project. They have years of deep experience on CI, automated testing, test tooling, and more. This experience has directly benefited ONAP. ONAP now has something called patch gating, where every path submission triggers an ONAP deployment followed by a set of automated tests. This increases the velocity of the project as people are not second guessing each other’s contributions. And it clearly increases stability. There are numerous other security enhancements also. Net-net the confidence you should have in putting ONAP into production continues to go up.
With support for full 5G orchestration, end-to-end slicing, Self Organizing Network (SON) enhancements, Fault Management/Performance Management (FM/PM) collection, close cooperation with 3GPP and the O-RAN Alliance Software Community, Configuration Management (CM) over NETCONF/RESTCONF/REST, a Configuration & Persistency service, and robust PNF support, is there a reason to not use ONAP for 5G?
As a company we think 5G and edge will exclusively be Kubernetes based (you can still have a few VMs supported via technologies such as Kubevirt and Virtlet). For this reason, I’m super excited to see the various enhancements in the K8s plugin of the MultiCloud project that make it easier to register multiple K8s cloud, define composite applications (built using CNFs and Cloud Native Applications or CNAs) that span clouds, and orchestrate these composite applications with a single click based on intent. Orchestration, day 0 configuration, networking aspects are all taken care of. Then for ongoing lifecycle management and day 1, 2 configuration, we can cut over to existing ONAP controllers and CDS. For slicing, we can use SO+OOF+UUI and the new slicing GUI/models/workflows.
You are probably getting a sense for our roadmap — we are furiously working on ANOD 5.0 that will be our first cloud native 5G/edge orchestration, lifecycle management, and automation product. We will also build a network slice manager on top.
In the meantime:
For more information on ONAP Frankfurt, check out the official page or the “What’s New in ONAP Frankfurt” webinar (I’m a panelist). Anything else on your mind? Feel free to contact us.
