- Created by Chaker Al-Hakim, last modified on Apr 28, 2020
Problem statement:
ONAP Model Driven Architecture is more focused on segregated model “parts” which are managed by each component or microservice. It is difficult to manage these segregated models confined within the component boundary but an ONAP wide model which can be acted upon by components or microservices would be more manageable.
Key Ideas:
- Use of provider/consumer pattern wherein an ONAP component or a micro service can act like a provider or consumer services on objects. Give an external view of the system in terms of API as providers and consumers
- Concept of an external model which can be worked on by an external API
- Concept of a provider registry - The Microservices do not talk to each other but act upon objects stored in the provider registry. Any change in provider registry by provider microservices or through external API is notified to the consumer microservices.
- Concept of a Service Façade which act like a proxy to the service implementation without exposing the complexities so that the required changes in microservices handling the service implementation can be worked on without impacting the consumers.
Benefits:
- Model driven concept can be driven through operation on objects. In this case workflows can be implemented as sequence of operation on objects.
- Can expose external interface to manage the state of objects
- Act like a shared state between components which can be centrally scaled/persisted
Link: Presentation
Problem Statement:
ONAP architecture requires capability to scale and to enable flexibility to work in a geo-distributed deployment scenario. This may further require proper mechanisms and technologies incorporated to synchronize state, ensure consistency across distributed deployments while providing capability for real time processing of data.
Key Ideas:
- Concept of a Real Time Data Event Stream Platform (RTDESP)- A bottom up approach with a RT Data Event Stream Collection, Aggregation, Transformation, Filtering
- Declarative model based approach for defining the end point
- A comparison of existing Kafka based DMaaP and new approach highlighting some of the limitations of DMaaP approach which is expected to be fixed by the new proposal or RTDESP
- DMaaP system does not support data synchronization
- DMaaP provides a Pub/Sub MOM with JSON payload and not tuned for polyglot environment
- In DMaaP Client/Server interaction is over TCP which is relatively slow in nature for message delivery
- Real Time nature of DMaaP is not clear
- A toolset for realizing the RTDESP consisting of – A DDS based Data Distribution Bus, Akka/Kafka based Collection FW, Beam and Flink for Transformation and Analytics, DDS based Cache/persistent storage
- RTDESP has two parts – a design time function which is used for defining workflow/pipe line stitching, a run time environment forming part of common service. There will also be some resources maintained in A&AI.
Benefits
- End point API independent message and data handling
- Real time message handling
- Geo distributed data synchronization for components in ONAP
- In-built storage for modelled data
Link: Presentation
Problem Statement:
- Lack of consistency in ONAP for defining the microservice structure
- Lack of cross leveraging of capabilities between components for microservices
- Lack of consistency in ONAP for defining the boundaries of microservice in terms of size or scope
- All the above limitations might prevent individual projects from attaining the S3P goals.
Key Ideas
- A meta model for micro services which can be used to generate the basic structure of a microservice for developers ,code to register with microservice bus, deployment artifacts
- A guideline for defining boundary for microservice following the Domain Driven Design principles and satisfying the bounded context
- Leveraging PaaS platform (for e.g: OpenShift or CloudFoundry) for deployment and runtime of ONAP microservices which can provide distributed concerns of microservices, can centrally control S3P from platform perspective, abstract microservices from infrastructure/platform level intricacies.
- Learnings and approach from Opendaylight wherein a YANG DSL is used for modelling
Benefits:
- Uniformity/Consistency across components/projects and helps in manageability of microservices in development and deployment.
- Leveraging PaaS will ease the life of developers as majority of the platform concerns can be offloaded to PaaS. Additionally best of breed platform components can be selected from PaaS without developing from scratch.
Link: Presentation
Problem Statement:
- No consistency in maintaining configurations across microservices. These configurations may be DB related access information, Access and topic information related to DMaaP, Logging configuration etc
- No capability for applying dynamic configuration updates on microservices , no mechanism for notifications
- Scale-out and HA would require consistent configurations across microservices to make it manageable
- No UI for updating microservice configuration
Key Ideas:
- To have a distributed KV store for storing the microservice configuration
- Option of using Consul or Etcd3 as distributed KV store
- Proposal to use Consul as ONAP already has Consul micro services
- Proposal for a PoC taking one microservice implemented in java and other one implemented in python, migrating the property and settings to consul.
Benefits:
- Uniform representation of configuration across microservices
- No duplicate configuration settings across microservices
- Scale out/HA of microservices to have consistent settings across them
- Reliable and distributed storage of configuration settings
Link: Presentation
From MS point of view resiliency to certain extend is already addressed by the OOM component built on Kubernetes. However state management is one area where micro services may have to leverage concepts from this proposal.
Problem Statement:
- A common high availability platform to build ONAP components with 5 9s of availability- This is currently lacking in ONAP
- Currently ONAP lacks a mechanism for components to support multi-site, geo-distributed, active-active services with efficient failover.
- Requirement for a common framework across ONAP for availability and resiliency problems. The common framework should be configurable and can be used along with ONAP components
Key Ideas:
- MUSIC: Multi-site geo-distributed database for state management at scale
- HAL: Configurable recipes for complex federation and resiliency protocols
- Conductor : Site selection service to satisfy constraints – May reuse some of the ONAP Optimization Framework modules/concepts
- All the above services are used in AT&T in production environment
Benefits:
- CHAP is flexible to adapt any high availability/resiliency deployment patterns – few examples shared in the architecture committee presentation
- CHAP has capability to load balance across sites using HAL to detect and transfer load
- MUSIC distributed state database can support different back end databases like Cassandra, H2, Maria DB
Link: Presentation
This proposal mainly focuses on the modularity at a component level, so that components can interoperate and the capabilities can be leveraged through well-defined APIs. The proposal also defines a model driven approach for defining ONAP components such as Orchestrators, Factories, Controllers, Data Collectors, and Advisory Functions, wherein each class of component can be defined in a normative way and can expose a standard set of APIs. Further to this the proposal gives direction for creating such modular class of components through a factory which can drive the LCM of components based on a standard model.
With a model to define the class of component it will be easy to drive the interoperability, have interface consistency and also drive commoditization of components. While the current scope seems to be limited at a component level, there may be a need in future to extend this mechanism of defining the standard interfaces and model at a microservice level. Currently it is debatable how the freedom of choice/degree of freedom for implementation of microservice can be balanced with the need of having a consistent model and APIs for microservices. This may depend on how microservices are packaged into components – i.e. as microservice, macro service (a first level disintegrated monolith) or mini service (monolith)
Problem Statement:
- Modular/Model driven implementation of ONAP components is required for allowing the operators to mix and match ONAP components with other operator preferred components.
- Modular implementation is also necessary for integrating with external domain management system which may be implemented using ONAP components or a subset functionality with ONAP like capabilities catering to specific technology domain.
Key Ideas:
- Conceptual model of a software unit – which can be a component or microservice which has a well-defined administrative and consumption end points. The implementation is decoupled from interface and uses resources which can be dedicated/shared, physically/logically isolated.
- The modular software unit must implement standard (normative) interfaces – for LCM, for describing capability, pub/sub interfaces for asynchronous communication.
- The use of factory pattern to implement a Controller which can create a class of software unit based on a model input. The factory maintains a catalog of units it can make, inventory of items it makes, accepts requests from clients for making software units and manages/monitors the state of software units. Essentially factory makes a set of provider instance which are software unit’s instances with specific provided capability to work on resources.
- A view on different flavors of providers and how they are internally structured
- A view on how different providers interact in runtime through a mechanism of acyclic graphs which can be configured as workflows (?)
Benefits:
- Defines a methodology for defining ONAP component functionality in a normative way through a set of standard functions
- Gives an approach for model driven architecture of ONAP by standardizing class of components, how they are constructed using a factory pattern and how their LCM is managed/monitored through catalogs, inventory
- Allows policy driven choice if multiple implementations are present
- Defines a common way to manage lifecycle of ONAP and non-ONAP components
Link: Presentation
- No labels