Cloud Native Microservices for Systems and ApplicationsPREM SANKAR GOPANNAN, ERICSSON

HTTP://TWITTER.COM/PREMSANKAR

Agenda

Business Requirements

Microservices overview

Design Patterns

Cloud Native Landscape

Key components

Containers

Kubernetes

Service Mesh

Business Requirements

- 5G- IOT- Digital Transformation

Product Requirements

Easy to Test

Easy to Scale

Easy to Test

Easy to Manage

Easy to Monitor

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

Key drivers for microservices

API-based End points*

Elasticity

Fault Tolerance

Agility

Infra and Location agnostic

Central Orchestration

Hardware evolution

Predictability

Upgradability

Testing

A/B Testing

Canary testing

Microservices Design Patterns

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

Microservices Design Patterns

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

CNCF Landscape

Lifecycle

Requirements

Service Orchestration

Infrastructure Orchestration

Business Process mapping

Audit and Validation

Security

WorkflowManager and Orchestrator

Continuous Integration

ContinuousDeployment

Monitoring

Design and Creation

Deployment and Execution

Operation, Analytics and Maintenance

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

Automation

•Ansible/Puppet

/Chef

Scheduler

(w/ docker/cri-o)

Kubernetes

Mesos

Swarm

Service Mesh

ISTIO

Linkerd

Monitoring

Prometheus

Other

alternatives(https://prometheus.io/docs/i

ntroduction/comparison/)

Tracing

Zipkin

Squash

Logging

ELK

Containers – Key enabler

Containers

Restriction

Cgroups

Capabilities

seccomp

Isolation

Namespace

Runtime

Docker

Rocket

Runc

Kubernetes

Master components

API Server – Frontend for K8S control plane

Scheduler

Control-manager

Node Controller

Replication Controller

Endpoints Controller

Service account and token controllers

Etcd – All clustered data is stored

Worker Node

Kubelet - primary node agent and watches pod that has been assigned to node

Kube-proxy – enables service abstraction by maintaining network rules on the host

Kubernetes components

Abstraction levels

POD – Encompasses the containers the pods that are related/microservice

Replication Controller – Defines pod count that corresponds to Service

Service – defines logical set of Pods

Ingress – connecting to external world

NFV Service – Deployment 1

PodAPodA

PodA

PodBPodB

NFV Service – Deployment 2

PodBPodAPodBPodA

Kubernetes Networking - Overview

CNI uses CNI Network plugin to setup container networking

(If container runtime is docker, CNM will not be used)

Plugin responsible for creating network interface to container

Plugin calls IPAM to setup IP address

Plugin needs to implement API for network creation and deletion

Kubernetes

CNI

Network Plugin IPAM

Service Mesh

Responsible for handling service-to-service communication

Apps are relieved from worrying about Traffic Management, Discovery, Service Identify and Security, Policy Management

Reliable delivery of requests

Complex topology of services

Developed as Network Proxy alongside application code

Sits above TCP/IP and assumes L3/L4 to be present

Some examples

Dynamic routing rules

Should it be routed to Production or Test (A/B testing)

Health of service and eject it is consistent

ISTIO ARCHITECTURE

Co

ntro

lD

ata

Pla

ne

ISTIO Components 1-2

Traffic Management

Pilot

Service Discovery

Load Balancing Pools

Routing Tables

Request Routing

Discovery and Load Balancing

Handling Failures

Fault Injection

Rules Configuration

Network and Auth

Policies and Control

Mixer

ISTIO Components 2-2

Istio Manager

Config

Istio Mixer

Policy Check and Telemetry

Istio CA

For certificates

Enovy

Service discovery with Consistency

ISTIO - Mixer

12 Factor App

I. Codebase

One codebase tracked in revision control, many deploys

II. Dependencies

Explicitly declare and isolate dependencies

III. Config

Store config in the environment

IV. Backing services

Treat backing services as attached resources

V. Build, release, run

Strictly separate build and run stages

VI. Processes

Execute the app as one or more stateless processes

VII. Port binding

Export services via port binding

VIII. Concurrency

Scale out via the process model

IX. Disposability

Maximize robustness with fast startup and graceful shutdown

X. Dev/prod parity

Keep development, staging, and production as similar as possible

XI. Logs

Treat logs as event streams

XII. Admin processes

Run admin/management tasks as one-off processes

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

REFERENCES

Design patterns for container-based distributed Systems -https://www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.pdf

Netflix - Failure simulation and stress testing in microservices architecture https://medium.com/netflix-techblog/chaos-engineering-upgraded-878d341f15fa

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/OpenstackODL

OVS/FD.IO

Microservices - VNF

ONAP

Design Time

Service Design and Creation

Policy

Runtime

Inventory

Controllers

Dashboard

Master Service Orchestrator

Security

Analytics

PROMETHEUS

Based on Google’s Borgmon system

Labelled time-series database

Provides

Inclusive monitoring

Rich data model

Powerful Query language

Dashboard

Scalable model

PROMETHEUS COMPONENTS

Server that collects and stores all data

Client libraries for instrumenting app code

Push gateway for short-lived jobs

Special purpose exporters

Alert Manager