Microservice Architecture: Proposals Submitted

Owned by Manoj Nair
Last updated: Dec 17, 2017
6 min read

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