Microservices Industry Perspectives (Copy)

Owned by Chaker Al-Hakim
Last updated: Apr 28, 2020
7 min read

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.