In the previous ONAP blog from this series, we looked at a high level view of what the new Linux Foundation Open Networking Automation Platform or ONAP project is all about, and what you can do with it. We also looked superficially at the three key architectural principles that, according to me, are Model Driven, Cloud Native and DevOps. In this blog, we will discuss the principle of Model Driven design in more detail.
As the name suggests, ONAP is all about automation. Instead of creating network services and the OAM (operations, administration and management) mechanisms manually, which results in large amounts of wasted effort and different results each time, a model driven approach allows the use of templates or models to quickly assemble network services, OAM recipes and the underlying infrastructure. A model driven approach results in the same outcome every single time! There is a another major benefit -- models do not require programmers, so a CSP does not have to hire an army of programmers to enable this automation.
The diagram below shows an analogy to better explain model driven.
Instead of the manual, custom and non-repeatable design on the left, a model driven approach on the right uses pre-designed and tested components to quickly assemble a design, that is automatically deployed in exactly the same manner each time. Additionally, models are service and vendor agnostic (unless of course they describe the VNF) making re-use even easier.
ONAP supports a model driven approach at three different levels -- 1) standard definition of models across all components of ONAP, 2) building blocks created by using these definitions and 3) a guided design studio to assemble these building blocks into a higher level design.
Model definitions in ONAP include structural models such as products (created by using one or more network service along with business data e.g. pricing), network services (e.g. VoLTE, vCPE etc.), VNFs (e.g. virtual Firewall), modules (that make up a VNF), virtual function components (or VFCs that make up a module), virtual links (VLs) that provide connectivity, ports etc. Of course new models can be defined, so this list is by no means exhaustive. ONAP also defines management data models such as VNF descriptors, licenses, engineering rules (e.g. only place VNF-a on a machine that supports DPDK) and recipe models such as policies, analytic microservices (e.g. string matching) or workflows (e.g. network service upgrade workflow).
These standard models can be used to create building blocks such as populated product definitions, network services, policies, closed-loop automation recipes, APIs, analytic apps and so on. And finally the guided design tool allows a designer to combine different models to create network services, closed-loop automation and other higher level design artifacts.
In summary, the architectural principles of ONAP are indeed elegant. Depending on who you talk to, he/she might highlight different principles. My top#3 list is Model Driven, Cloud Native and DevOps. In this blog we saw how a model driven approach promotes extreme automation without having to write a single line of code. We will look at cloud native and DevOps in subsequent blogs.
Until then:
Sign up for our 1/2 day ONAP100 in-person training course (offered jointly with Cloudify) in Santa Clara on November-10, 2017. This course will give you a complete picture of what ONAP is, its architecture and 29 constituent projects in the upcoming Amsterdam release. There's early-bird discounts and special discounts for CORD/TIP conference attendees.
If you are unable to make the class, you can also attend the "ONAP Overview: Navigating its Many Projects" webinar (jointly with Mirantis) scheduled for November-15, 2017.
