I have been talking about ONAP via a blog series (last blog here). It's perhaps useful to take a break and discuss the latest Amsterdam release. I think this release is important for three reasons:
1. It shows that the mega-merger of ECOMP and Open-O actually works. Perhaps more important that the codebase merger is collaboration between people and that they were able to get a release out, when they said they would. This is a strong confidence building indicator.
2. It proves that the key architectural principles of ONAP such as model drive, cloud native, DevOps, real-time, closed loop automation etc. actually work in real-life. These are new and rather futuristic concepts that help move operators from a break-fix mindset to plan-build one. And with Amsterdam, the future is here.
3. It shows that the release is useful through two concrete use case blueprints: VoLTE and residential vCPE. Of course, you can create any service using ONAP; it's a general purpose platform not restricted to these narrow services, but having these two use cases shows that ONAP can do something useful. It also provides potential users with a concrete step-by-step example of how to extract value from ONAP.
So now we get to the key question:
Telecom operators should be thinking about an ONAP POC with the residential vCPE use case. The residential vCPE use case is 100% open source, so there are no vendor dependencies. Doing a POC will expose you to all the architectural concepts of ONAP.
Maybe you don't have a strong enough business case to package your VNF for ONAP yet, but we all know that sooner or later you will have to bite the bullet on this. It's a matter of time. An ONAP POC with the residential vCPE use case can help you understand how ONAP works and how you could package up your VNF for ONAP in the future. You can even start thinking about how you might differentiate your VNF for ONAP.
Looking for help? Feel free to contact us for training, deployment services and VNF packaging around ONAP.
