The Significance and Importance of the ONAP Amsterdam Release

The first release of ONAP, named Amsterdam, touched down just last week, November 20th, with a lot of expectation as well as preparation to get started on Beijing – with the ONAP developer summit happening just a couple of weeks following the Amsterdam release. The large majority of the work that went into the initial release was centered around fusing the code between the two original projects that comprise ONAP – ECOMP and Open-O.  The team at Cloudify is excited to have taken part in contributing code to a number of core components including the OOM, and ARIA on the service orchestration layer.

While it was met with criticism and doubt in advance of this first release, ONAP, like some of the most popular and widely adopted open source projects – from OpenStack through OpenDaylight – will need to go through the known maturity cycles that such collaborative projects undergo until they stabilize and are production-ready.  Assuming a first release will be ready for production is simply an unrealistic expectation, although it can be done with some custom enhancements.  

The most important thing to be remembered with the Amsterdam release is that it is much more than a project and code base; ONAP is an ecosystem that has brought together carriers representing close to 60% of the world’s subscribers. It also brought standards bodies and vendors together to collaborate, something that before ONAP was almost impossible to do at this scale.

Arpit Joshipura, general manager of Networking & Orchestration for the Linux Foundation said something similar and put the criticism into perspective by reminding the critics of the three main goals of the ONAP release.  The first is that it is important to remember that ONAP is a platform not a product built with the intention of being able to mix and match other products from the ecosystem within the platform.  This means that the expectation for ONAP to be able to be a one-stop-shop for all networking automation needs is also unrealistic.

In addition, merging two highly disparate codebases – as was done with ECOMP and Open-O is no simple undertaking, and just this task at hand was a very ambitious goal for the first release – and the results speak for themselves.  From here, with the two merged codebases ONAP can now focus on adding the code and features to begin delivering on this open platform geared for Telcos and service providers looking to break the lock-in cycle.
This first iteration of ONAP was largely focused on the three primary and community-requested use cases of VoLTE, network on demand, and vCPE – and this is only the beginning. One extremely significant milestone with ONAP was bringing the standard modeling discussion to the forefront, with TOSCA which is also being adopted by other large standards bodies such as MEF and TM Forum.

And it appears that ONAP is attempting to learn from the mistakes of other open source projects – by bringing in additional projects into the ecosystem – instead of reinventing the wheel.  This can be seen through the significant amount of codebases and projects outside of the Gerrit repository that are being integrated with ONAP.  Another important milestone with ONAP is that it is the first major project of its kind with a clear direction toward cloud native, container-based architecture.

Building a project that comes from the cloud native mindset at the outset changes the game entirely.  This will be the first project of its kind built for dynamic, cloud environments, focusing on multi-cloud interoperability and specifically the networking aspects that add the complexities when trying to make multi-cloud a reality.
To me, personally, this is exciting – and I can’t wait to see what’s in store for this project.

Learn more about ONAP in this upcoming webinar and register for our next ONAP fundamentals training as well. You can also see how Cloudify and ARIA work to enhance ONAP in this solution brief. Keep up to date with project ARIA in this podcast.
Here are some blog posts on ONAP and Cloudify:
TOSCA ONAP Service Orchestration with Cloudify and ARIA
Model-Driven ONAP Operations Manager (OOM) On-boarding with TOSCA and Cloudify
VNF Onboarding, TOSCA, and ONAP – Why Operators and VNF Vendors Need to Care