Open source Approach to Design

and Deployment of Microservices

based VNFPREM SANKAR G, ERICSSON

HTTPS://TWITTER.COM/PREMSANKAR

Agenda

Microservices overview

VNF Characteristics

Opensource Ecosystem

Mapping to ETSI NFV architecture

Design Patterns

VNF Deployments

ONAP

Microservices – Quick Intro

• Reference – Martin Fowler, http://martinfowler.com

Principles that drive Microservices

architecture

• Services must be loosely coupled so that they can be developed, deployed and scaled independently

• Organized around business capabilities

• API Focused

• Smart endpoints and dumb pipes

• Decentralized Governance

• Decentralized Data Management

• Infrastructure Automation (infrastructure as code)

• Design for failure

• Evolutionary Design

Network Functions - Evolution

PNF VNF

Hypervisor

Microservices VNF

Hardware

µs µs µs

µs µs µs

µs runtime engine

Key drivers for microservices VNF

Business needs

5G, IOT

Hardware evolution – OCP

Elasticity

Fault Tolerance

Agility

API-based/End points

Infra and Location agnostic

Central Orchestration

Predictability

Upgradability

Testing

A/B Testing

Canary testing

Lifecycle

Workflow

Manager and

Orchestrator

Continuous

Integration

Continuous

DeploymentMonitoring

Design and

Creation

Deployment

and

Execution

Operation,

Analytics and

Maintenance

Requirements

Service Orchestration

Infrastructure Orchestration

Business Process mapping

Audit and Validation

Security

ETSI NFV Architecture

Microservices Design Patterns

• Reference – Chris Richardson http://microservices.io/patterns/microservices.html

Microservices Design Patterns for VNF

Decomposition Pattern

Subdomain context

Service discovery Pattern

Database per service Pattern

Keep each microservice’s persistent data private to that service and accessible only via its API

RDBMS design approaches

Private-tables-per-service – each service owns a set of tables that must only be accessed by that service

Schema-per-service – each service has a database schema that’s private to that service

Database-server-per-service – each service has it’s own database server.

Circuit Breaker

API Gateway Pattern

Opensource Ecosystem

• Workflow Manager and Orchestrator

• ONAP , ARIA, OSM

• Design and Deployment

• CI/CD Pipelines

• Jenkins

• Fabric8 (Jenkins, Kubernetes and Docker)

• Other options – goCD, concourse.ci

• Ansible/Puppet/Chef

• Execution/NFVi

• Kubernetes with ODL/CANAL/Weave, OPNFV

• Service Mesh - Istio

• Monitoring

• Prometheus and other alternatives (https://prometheus.io/docs/introduction/comparison/)

• Tracing

• Zipkin

• Logging

• ELK stack

VNF Deployment scenario

Neutron Plugin or Gluon/Proton

Linux Linux Linux Linux

Kubernetes

Datacenter Hardware

Linux

OpenStack

OVS

App

Orchestration Systems

OpenStack APIs

OpenDaylight

Kubernetes APIs

CNI Plugin

KVM KVM ContainerRT

Container RT

App App App

VM Application Container Application

AppApp App

ETSI NFV Architecture

OSM

ONAP

Kubernetes/Openstack

ODL

OVS/FD.IO

Microservices - VNF

ONAP

Design Time

Service Design and Creation

Policy

Runtime

Inventory

Controllers

Dashboard

Master Service Orchestrator

Security

Analytics

Topology and Orchestration Specification for Cloud Applications

Goals

Automation of service deployment and management

Portability

Interoperability

Vendor-Neutral

Model to define structure of service and how to manage it

Service composition

Topology Template – Structure of a service

Plans to manage service during its life time

TOSCA 101

TOPOLOGY TEMPLATE

› Service template

– Topology Template

– Node Type

– Relationship Type

– Plans

› Plans

– Parallel Execution

– Error Handling

– Audit/Trace

– Human tasks

MODEL APPS

Container Orchestration Engine Integration

- OpenDaylight

Host OS

Open vSwitch

Host OS

Open vSwitch

VM

Container

App

Container

App

Container

App

VLAN’s

Orchestrator

OpenDaylight

Kubernetes / Docker

Kuryr

Neutron / Gluon

Container

App

Container

App

Container

App

Container

Mgt

(docker,

kube-

pxy)

Iptables / NAT/FW

Native

• Reference – ODL COE project, http://wiki.opendaylight.org/view/COE:Main

Q&A

Any organization that designs a system

(defined broadly) will produce a design

whose structure is a copy of the

organization's communication structure.

-- Melvyn Conway, 1967