Microservices Industry Perspectives (Copy)

ETSI EVE 011 work item titled “Specification of the Classification of Cloud Native VNF implementations” has done some assessment on the microservices characteristics especially for the VNFs. Following are some of the characteristics

1. Automated deployment
2. Independent deployment and management (from other services)
3. Enable elasticity, i.e.  to be able to scale, in or out, independently of other services in the same application.
4. Reduce side effects across collaborating services, e.g. scaling only portions of an application that need the additional capacity, and being able to update/upgrade portions of the application without impacting users
5. Improve fault isolation: larger applications can remain largely unaffected by the failure of a single module.

EVE 011 paper further elaborates some of the key non-functional aspects that need to be considered in a cloud native VNF. The characteristics mentioned above from the ETSI work item is quite relevant for defining the scope of the microservice with in ONAP along with the non-functional characteristics.  Some of these non-functional characteristics include

• Resiliency – Different levels of Resiliency
• Redundancy – By having more instance of “micro-components”, also factoring the redundancy model (active-active, active-standby), mode of recovery, performance metrics related to redundancy model, failover time, Single point failure, Risk Factor.
• Fault Monitoring and Fault Detection : Covering the Fault Monitoring Metrics, Fault Logging Configuration, Fault Detection Scheme.
• Scaling : Scaling Out/In

The above characteristics are good reference for incorporating at microservice level and component design level to align with the cloud-nativeness envisioned by the industry. 

Cloud Native Computing Foundation is driving the cloud native concepts, especially promoting the use of containerized microservices and associated tool sets for building a cloud native application stack. One of the solutions promoted by CNCF is the service mesh and there are multiple projects supporting the service mesh concept in CNCF stack. In its essence service mesh is a software defined service plane for microservice with a service controller to manage the policies, service discovery etc. To enable the service mesh topology, each microservice is equipped with a side car proxy which handles all the interaction needs (service discovery, communication patterns) required by particular microservice. Each side car proxies are centrally controlled using a service controller, which enables communication policies between microservices as well as implements some of the common needs such as logging, discovery, load balancing etc. In CNCF stack Linkerd and Istio are few of the projects which enable the service mesh capability.

Service mesh comes with multiple benefits in a microservices architecture – Specific to ONAP it can handle some of the common services more efficiently, for example the communication between micro services can be managed in a more distributed fashion without worrying about the overheads of managing the seed code, additionally no dedicated component is required for service registration and discovery. In addition service mesh comes with inherent capability to support – resiliency, scaling support and communication patterns (such as routing, failure recovery, load balancing etc.)

Serverless is a natural evolution of microservices. In Serverless architecture microservices are further broken down into short lived functions which are executed in response to events. Another characteristic is the distributed nature of the functions which can be executed flexibly without deployment constraints. Serverless also brings in benefit such as - flexible/on-demand scaling, rapid deployment, less constraint on framework or platform from development point of view etc. While the concept is god enough, considering the fact that this concept is not mature enough in market and among the projects within ONAP, this may be a future considerations.  Additionally most of the ONAP code is brownfield in nature, i.e based/extended from seed code. So adaptation of a new architecture paradigm is time consuming and effort intensive. However this may be a consideration for any new projects/components that may be proposed in ONAP. 

Platform as a Service (PaaS) solutions (for e.g. OpenShift, CloudFoundry, Mesos) comes with many advantages such as isolation from hardware intricacies, distributed deployment options through clustering, resiliency of the deployed application through built in mechanisms, centralized management of S3P capabilities, focus on the application than on the containers/servers/HW, built-in mechanism for messaging/information exchange between application components in a location agnostic manner.  With all these advantages PaaS solutions become suitable for deploying applications constituting microservices.  While Container as a Service (CaaS) platform such as Kubernetes provides some of these benefits, it is not as sophisticated and manageable as in a PaaS platform; also the PaaS platform gives the notion of an application rather than a container.

For ONAP there is already a plan to use Kubernetes for deploying the dockerized microservices through the ONAP Operations Manager (OOM) Project. It will be a natural extension to leverage some of the PaaS solutions so that some of the components built from scratch in ONAP and are less mature can be replaced by more mature and stable variants from PaaS.  Additionally some of the key limitations in ONAP with respect to achieving S3P levels can be easily gained by a simple adoption of PaaS. Majority of the PaaS solutions available today has built in support for Kubernetes and Docker/LXD/LXC containers. 

Open Service Gateway initiative focus on defining specifications for building a modular service framework for Java based implementations. In OSGi compliant system microservices are built as bundles which can be deployed on demand and can make the capabilities discovered, dependencies defined. OSGi specifies a layered microservices architecture constituting of bundles, services, service registry, life cycle management of microservice bundles, security aspects covering the namespace under which each microservice context exists, and modules which define the encapsulation concept for microservices.

In ONAP, SDNC and App-C uses OSGi based micro services concept supported by the Common Controller SDK. From overall architecture perspective, it may be counterproductive to propose or enforce OSGi based microservices implementation because not all components are built on Java VM and OSGi has complexities in integrating existing third party toolsets unless those are exported as bundles to be executed in an OSGi environment. But there are some good ideas that can be leveraged and implemented in a container based microservices implementation – such as the service registry, framework such karaf capabilities in terms of common service libraries/CLI, clustering support through cellar, management capabilities exposed through JMX/Jolokia etc.

One other concept that ONAP can borrow from OSGi based microservices is the concept of Metadata which gives information about the OSGi bundle. An advanced concept called feature which is used in Karaf based OSGi implementation to represent a deployment unit with configurations. 

TMForum specification – IG11118 – OSS, BSS Future architecture gives the concept of a Management and Control Continuum (MCC) where in the Management functions and Control functions are NOT looked separately but as one continuum.  This is considered as one of the key building block for the future mode of operation (FMO) meant for the uniform operations across hybrid services (spanning physical and virtual resources). The specification also gives an architectural view of such a management and control continuum component which does not demarcate management and control components/functional capabilities and has potential to stretch across BSS/OSS, NMS/EMS, MANO, SDN Controller functional blocks.

In the proposed MCC architecture an MCC component can be composed into an MCC System or MCC Solution – for example an SDN Controller forming a MCC solution assembly, composed of many MCC components. The architecture also gives flexibility to compose MCC components in to another MCC component assembly which can be a branded component – for example EMS. The composition of such MCC components, Solutions, Systems can form MCC Application.

Mapping the MCC architecture to ONAP, the notion of MCC Component can be mapped either to an ONAP component such as DCAE or A&AI, or it can be mapped to a sub function (microservice) for example DCAE controller in DCAE.  TMForum suggests defining the minimum functionality to exist as an MCC component which can be assembled to form MCC solution, MCC System, MCC application or another assembled MCC application itself. The context of MCC Component can vary as it is composed into different domain functions. This is more akin to the bounded context pattern in Domain Driven Design (link) – i.e. defining boundaries based on domain functions. So MCC Component can be used as a base for defining/identifying microservices boundaries. Additionally the TMForum specification discussed above also elaborates future mode of operation component requirement (such as APIs, intent based interface, virtualization)  which may be useful in defining the capabilities to be exposed by a microservice. 

• OSM

OSM follows a container based implementation approach but not strictly microservices based approach. This is based on the key architectural principle of maintaining simplicity. OSM components are built in to LXD containers and each of these containers can be a monolith in its own sense. Inter-Component interactions are implemented through REST APIs. OSM follows a model driven architecture principles – but primarily use this concept for the NS and VNF models and not for internal components.

• Opendaylight

Opendaylight follows the microservice architecture principle and uses OSGi runtime enabled through Apache Karaf. Opendaylight also supports a model drive approach for defining the micro services, where in each micro service is modelled using YANG DML. Opendaylight supports numerous tool sets to process the YANG models – for parsing, code generation, RESTCONF etc. The MD-SAL framework available in Opendaylight functions as a common platform layer which enables interaction between microservices and also manages the configuration and operational state of micro services. MD-SAL also supports scalable deployments enabled through clusters implemented using akka framework. MD-SAL supports an event sourcing approach wherein the object state changes are stored as series of event logs which can be replayed for recovery of state. Following Yang model for micro services Opendaylight can manage three facets of microservice – data/state, rpc/actions, notification/events.

• ONOS

ONOS follows microservice architecture and uses OSGi runtime enabled through Apache Karaf. Unlike Opendaylight ONOS does not have a common framework like MD-SAL or does not follow a model driven approach. But ONOS supports some of the interesting concepts like cluster based deployments, efficient entropy management, state consistency, data sharding etc. ONOS variant supported by Ciena BluePlanet is also available as Docker container, to leverage container based microservice use cases in a wider scope.

• OpenBaton :

OpenBaton uses a ‘microservice-like’ approach but not strictly leverage on any microservice framework. The modules are based on Spring Framework and interaction between microservices is enabled through RabbitMQ message bus and REST API. 

• CORD (update by Srinivas)

Based on last OPEN CORD conference, It appears that ONOS and XOS transforming itself to Cloud-Native.  They seems to be moving ahead with cloud-native technologies such as

• Services as Docker containers.
• Orchestration using K8S.
• Service mesh using ISTIO (Service registration & discovery,  Visibility,  Circuit breaker functionality, load balancing etc...)
• Secure communication using Mutual TLS
• CNI for VNFs from ONOS (It is not clear whether they intend to go ahead with OVS CNI or move to OVN CNI)