We've discussed ONAP architectural principles in the past, but I felt it might be good to review them again as I have seen some confusion about the ONAP architecture. The architecture principles of ONAP (as described by the community) are classified into 4 categories:
- Scope: Lifecycle support; resource, vendor, and service agnostic; common information model; strive for standardization; and integrated and standardized catalog
- Business imperatives: Policy driven automation, model driven, self service and user focused, cloud agnostic, backwards compatible
- Implementation approach: microservices, shared services, CI/CD support, integration friendly/standard API, layered software abstractions, platform system data model
- Deployment/resiliency/scalability support: Cloud environment support, scalability, availability & resiliency, security, platform plumbing, lightweight and modular, runtime independence from the internet
Specifically, let's discuss some of the key items from the list that I believe to be especially interest
- ONAP is a containerized (microservices based) application deployed using Kubernetes (k8s). In this manner, ONAP can be deployed on as few or as many bare metal or virtual machines as required by the performance and availability needs of the user. It can scale to 1 VM for say development purposes, while the official community validation is across 15 VMs. And services do scale horizontally as well, e.g., DCAE can scale horizontally to handle the required telemetry load.
- ONAP is model driven, and to the extent possible, inputs to ONAP are provided as models. In addition to the usual infrastructure-as-code benefits, a model driven approach reduces the need for programming and allows for changes to be made outside of the ONAP release cycle.
- ONAP supports CI/CD. Not only is ONAP developed using a CI flow, it also expects VNFs and other vendor software products to be updated all the time—in a CI/CD manner.
- ONAP is modular. The scope of ONAP requires that there be multiple components and services work together (at the highest level the components are design, orchestration, lifecycle management, inventory, and service assurance/automation). It is very common for users to utilize just a subset of ONAP services. For example, one end user has used just a few projects (Policy, A&AI, VES collector, DMaaP) for a specific use case. Others have done demos with just DCAE+Policy+DMaaP+APP-C while yet others have used just the orchestration+LCM piece leaving out DCAE+Policy completely.
Hopefully this discussion answers the title of my blog—the ONAP Dublin architecture is certainly microservices based and not monolithic. These microservices can be scaled and distributed. In fact, if you take a system such as DCAE, its nodes are HDFS nodes, and the horizontal scalability of HDFS is well known.
Another point of confusion is about the sizing or scalability of ONAP, i.e. that it might only work as 1 monolithic VM. As we saw above, ONAP has no problem being spread across multiple bare metal or virtual machines given that it is a containerized application that uses k8s for its orchestration. An ONAP Dublin deployment has over 200 k8s Pods or microservices. And you could literally distribute these services across 200+ VMs if you so desired (I would not recommend this) and more if you started to scale services.
Curios to learn more about ONAP? Feel free to take one of our ONAP trainings or download the Aarna.ml ONAP Distribution.
