The 2nd release of the Linux Foundation Open Network Automation Platform (ONAP) project, titled Beijing, occurred on 6/12.
The operators and vendors I’ve talked to ask questions such as: “Is ONAP going to make it? … With other proprietary orchestrators further ahead in terms of functionality and VNF support, should I bother with ONAP? ... Is ONAP mature enough?” My answer is simple — remember CloudStack, Eucalyptus, Nimbula? Not many people remember these names. These were competitors to OpenStack up until 2013/2014. Users had similar concerns regarding OpenStack at the time, but OpenStack is the de facto VIM in 2018 (that could change with Kubernetes, but that's a topic for another day). Similarly, with solid community momentum, significant operator participation and a holistic architectural approach, I believe ONAP will end up being the de facto network automation (aka MANO++ aka orchestrator) software stack.
What’s in the release, you ask. First, given the name Beijing I just had to find an appropriate chinese proverb. The proverb 小洞不补，大洞吃苦 apparently means: “If small holes aren't fixed, then big holes will bring hardship”. I think this sums up the Beijing release quite well. A large percentage of the Beijing release comprises work done under the covers (non-functional enhancements) to improve the overall quality of ONAP.
Having said that, I view Beijing enhancements in three buckets:
Non-functional improvements are a major part of the Beijing release. In fact, S3P (Scalability, security, stability and performance) was a major area of focus for each of the 31 ONAP projects.
Additionally, the Beijing release has a number of important functional enhancements. The first enhancement was blueprint enrichment — manually triggered scaling (vDNS, VoLTE blueprints), change management (vCPE blueprint) and policy driven VNF placement (vCPE blueprint). The last item also included hardware platform awareness (HPA) that is critical to achieve the right price/performance characteristic for your network service. Second, ONAP northbound APIs are in the process of being harmonized with MEF Allegro, Legato and Interlude APIs and TMForum 633, 641, 638, 640 and 652 APIs. This API harmonization is very important to have consistent APIs for OSS/BSS. Third, the OOM project, that deploys a containerized version of ONAP using Kubernetes (k8s) and Helm, has been improved such that all ONAP components including DCAE have been containerized can now be installed and configured using k8s.
Lastly, the Beijing release has two new projects. The MUSIC project provides standard services to distribute applications across multiple clouds. The key idea of MUSIC is to help an application get to 5x9s availability with <=3x9s of infra (I'm sure that's music to your ears ;-). The Benchmark project tests the performance of ONAP across functionality, scalability and security with the goal of finding bottlenecks in these areas.
Want to learn more? Join our “What's new in ONAP Beijing Release?” webinar on 7/24 at 9:00AM Pacific Time.
Ready for more formal learning? Check out our training services.
Ready to get your hands dirty? View our products & services.
