Draft Architecture Principles
Architectural principles provide guidelines when making architecture decisions. The principles are not requirements (functional or non-functional), nor should they specify the design of the system.
1.Virtualized Software Based Applications
Flexibility in component deployment is important to ONAP functionality. All components in ONAP should be virtualized, preferably with support for both virtual machines and containers. All components should be software-based with no dependency on hardware platform. However, where hardware capabilities can enhance an ONAP component, those capabilities can be used if not required for the component to function.
2. Decoupled Applications Modules/Microservices
All components in ONAP should avoid tight coupling between other components. Components should be service-based with clear, concise function addressed by each service, following principles of microservices.
3. Shared Standard Cloud Platform
All components in ONAP should be able to run on a shared standards-based cloud platform. Ideally, the cloud platform implementation should be pluggable and transparent to the ONAP components.
4. Software Modularity and Reusability
Code within ONAP should be designed in a modular fashion & reusability is highly encouraged across components. Where applicable, reusable components can be provided as shared services across ONAP components.
5. Open Platform and APIs
An open, standards-based architecture with well-defined APIs fosters interoperability both within ONAP and across complementary projects and applications.
6. Supplier Agnostic
The ability for ONAP to be used by various users worldwide dictates the need to avoid dependency on any single supplier(s). All efforts within ONAP should be agnostic to a supplier’s function, application, or code.
7. Model-Driven
All aspects of a network service design in ONAP should be model-driven, avoiding, where possible, programming code. This allows for a catalog-based reusable repository for a network service lifecycle.