Microservice Architecture: Proposals Submitted

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 

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