This document discusses cloud native microservices and key components for implementing them. It provides an overview of microservices principles and design patterns, and describes the cloud native landscape including containers, Kubernetes, service meshes like Istio, and other open source tools. It also discusses architectures like ONAP and considerations for deploying virtual network functions using microservices.

1. Cloud Native Microservices
for Systems and
Applications
PREM SANKAR GOPANNAN, ERICSSON
HTTP://TWITTER.COM/PREMSANKAR

2. Agenda
 Business Requirements
 Microservices overview
 Design Patterns
 Cloud Native Landscape
 Key components
 Containers
 Kubernetes
 Service Mesh

3. Business Requirements
- 5G
- IOT
- Digital Transformation

4. Product Requirements
Easy to
Test
Easy to
Scale
Easy to
Test
Easy to
Manage
Easy to
Monitor

5. Microservices – Quick Intro
• Reference – Martin Fowler, http://martinfowler.com

6. 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

7. 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

8. Microservices Design Patterns
• Reference – Chris Richardson
http://microservices.io/patterns/microser
vices.html

9. 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

10. CNCF Landscape

11. Lifecycle
 Requirements
 Service Orchestration
 Infrastructure Orchestration
 Business Process mapping
 Audit and Validation
 Security
Workflow
Manager and
Orchestrator
Continuous
Integration
Continuous
Deployment
Monitoring
Design and
Creation
Deployment
and Execution
Operation,
Analytics and
Maintenance

12. 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

13. Containers – Key enabler
 Containers
 Restriction
 Cgroups
 Capabilities
 seccomp
 Isolation
 Namespace
 Runtime
 Docker
 Rocket
 Runc

14. 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

15. 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
PodA
PodA
PodA
PodB
PodB
NFV Service – Deployment 2
PodBPodA
PodBPodA

16. 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

17. 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

18. ISTIO ARCHITECTUREControl
DataPlane

19. 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

20. ISTIO Components 2-2
 Istio Manager
 Config
 Istio Mixer
 Policy Check and Telemetry
 Istio CA
 For certificates
 Enovy
 Service discovery with Consistency

21. ISTIO - Mixer

22. 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

23. 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

24. REFERENCES
 Design patterns for container-based distributed Systems -
https://www.usenix.org/system/files/conference/hotcloud16/hotcloud16_burns.p
df
 Netflix - Failure simulation and stress testing in microservices architecture
https://medium.com/netflix-techblog/chaos-engineering-upgraded-
878d341f15fa

25. 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
App
App App

26. ETSI NFV Architecture
OSM
ONAP
Kubernetes/Openstack
ODL
OVS/FD.IO
Microservices - VNF

27. ONAP
 Design Time
 Service Design and Creation
 Policy
 Runtime
 Inventory
 Controllers
 Dashboard
 Master Service Orchestrator
 Security
 Analytics

28. PROMETHEUS
 Based on Google’s Borgmon system
 Labelled time-series database
 Provides
 Inclusive monitoring
 Rich data model
 Powerful Query language
 Dashboard
 Scalable model

29. 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