Microservices - Hitchhiker's guide to cloud native applications

MicroservicesHitchhiker’s guide to cloud native applications

Andreas Evers @andreasevers

Stijn Van den Enden @stieno

Martin Fowler

“The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight

mechanisms, often an HTTP resource API. These services are built around business capabilities and independently

deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services,

which may be written in different programming languages and use different data storage technologies.”

James Lewis

Characteristics of a Microservice style


• Small and focussed on 1 capability • easier to understand • IDE and deployment faster for 1 service

• Provide firm module boundaries with explicit interface • Harder to violate boundary in development

• Independent • Development • Release and deployment • Scaling

• Loosely Coupled • through lightweight communication

• Fault Isolation vs. bring all down.

• Decentralised choreography • vs. central orchestration • vs. central point of failure

• Allows try-out of new technologies. • Re-write can be limited to 1 service

• Impact Analysis stops at boundary


• Decentralised data • polyglot persistence

Strong Module Boundaries Distribution

Eventual Consistency

Independent DeploymentOperational Complexity

Technology Diversity

Security Segmentation

Separate Scale-out

Parallel Development

Is this any different from SOA?

SERVICE ORIENTED ARCHITECTURE?Yes, it’s SOA … but different implementation approach:

Classic SOA integrates different applications as a set of services

Microservices architect a single application as a set of services


Microservices

Enterprise Service Bus

WS* WS* WS* WS* WS*

WS* WS* WS* WS* WS*

Workflow Engine

Intelligence

Orchestration

integrates different applications as a set of services


business platform

accounting service contract

service

ordering service

logistics service

prospects service

capability X service

capability Y service

external integrationsbackends

{ API } { API }{ API }

{ API } { API }

{ API }{ API }

{ API } { API }

{ API } { API }



Typical implementation solution differs!

Heavy-weight

ESBWS*/SOAP

Orchestration

License-drivenTarget problem:

Integrate (Legacy) Software

Intelligent Communication Layer

Light-weight

HTTP/REST/JSON

Choreography

Target problem: Architect new Business Platform

Dumb Communication Layer

Intelligent Services

Any practical advice on how I can start building the microservice stuff?

side note: Domain Driven DesignTackling complexity by abstracting the business domain concepts and logic into a

domain model and using this as a base for software development

“In order to create good software, you have to know what that software is all about. You cannot create a banking software system unless you have a good understanding of what

banking is all about, one must understand the domain of banking.”

Eric Evans

Domain driven design deals with large complex models by dividing them into different functionally bounded subdomains and the explicitly describing the

interrelations between these subdomains.

Bounded contexts

AccountingInventory

BillingOrdering

Functional decomposition of the business domain

Functional decomposition of the business domain

AccountingInventory

BillingOrdering

customer

Invoice

balance

order

item

item

stock order

order

item

incoming cash

outgoing cash

stock

Benefits of functional decomposition

AccountingInventory

BillingOrdering

customer

Invoice

balance

order

item

item

stock order

order

item

incoming cash

outgoing cash

stock

Benefits of functional decomposition

Applying services to bounded contexts

Accounting ServiceInventory Service

Billing ServiceOrdering Service

customer

Invoice

balance

order

item

item

stock order

order

item

incoming cash

outgoing cash

stock

AccountingInventory

BillingOrdering

customer

Invoice

balance

order

item

item

stock order

order

item

incoming cash

outgoing cash

stock

take notice.

Sam Newman

“If you’re coming from a monolithic system point of view, you’ll have to get much better at handling deployment, testing, and

monitoring to unlock the benefits we’ve covered so far. You’ll also need to think differently about how you scale your systems and

ensure that they are resilient. Don’t also be surprised if things like distributed transactions or CAP theorem start giving you

headaches, either!”

What do we need to get started?

Implementing a Microservice

java -jar payara-micro.jar --deploy test.war

Service Discovery

NodeClient

Node

Node

Node

Node

?

Loadbalancer

Single Point of Failure Manual configuration management

Client

Node

Node

Node

Node

?

Registry

register

health

lookup

Node

🚫

unregister

K/V

K/V

K/V

K/V

K/V

/etc distributed

raft - leader election

//Adding a value $ curl http://127.0.0.1:2379/v2/keys/message -XPUT -d value="Hello world”

//Quering $ curl http://127.0.0.1:2379/v2/keys/message { "action": "get", "node": { "createdIndex": 2, "key": "/message", "modifiedIndex": 2, "value": "Hello world" } }

//Delete $ curl http://127.0.0.1:2379/v2/keys/message -XDELETE

Operations

K/V

K/V

K/V

K/V

K/V

/etc distributed

raft - leader election

SkyDNS

//registration $ curl -XPUT http://127.0.0.1:4001/v2/keys/skydns/local/production/preference/1 \ -d value=‘{“host”:”service5.example.com”,"port": 8080, “priority”:20}'

Operations

% dig @localhost SRV preference.production.local

;; ANSWER SECTION: preference.production.local. 3600 IN SRV 10 20 8080 service5.example.com. preference.production.local. 3600 IN SRV 10 20 8081 service4.example.com.

;; ADDITIONAL SECTION: service4.example.com. 3600 IN A 10.0.1.125 service5.example.com. 3600 IN A 10.0.2.126

Operations

A HashiCorp Project.

https://www.consul.io/

K/V

K/V

K/V

K/V

K/V

Distributed Key/Value Store

http

dnsClient

raft - leader election gossip - node detection

Node

{ "service": { "name": "preference", "tags": ["spring"], "port": 8000,

"checks": [ { "script": "/usr/local/bin/check_preference.py", "interval": "10s" } ] } }

Service Registration

$ dig @127.0.0.1 -p 8600 preference.service.consul SRV ... ;; QUESTION SECTION: ;preference.service.consul. IN SRV

;; ANSWER SECTION: preference.service.consul. 0 IN SRV 1 1 8000 agent-one.node.dc1.consul.

;; ADDITIONAL SECTION: agent-one.node.dc1.consul. 0 IN A 172.20.20.11

Service Query (DNS)

$ curl http://localhost:8500/v1/catalog/service/preference [{"Node":"agent-one","Address":"172.20.20.11","ServiceID":"preference", \ "ServiceName":"preference","ServiceTags":["spring"],"ServicePort":8000}]

Service Query (http)

Static

Dynamic

Loadbalancer Loadbalancer

MicroService MicroService MicroService MicroService MicroService

Web Front End

Web Front End

Web Front End

Web Front End

Web Front End

MicroService MicroService MicroService MicroService MicroService

A

B

Midtier Service Registry

MicroServiceregister

renew

get registry

eureka

ribbon

https://github.com/Netflix/eureka

https://github.com/Netflix/ribbon

Apache ZooKeeper™

synapse - HAProxy based service discovery/routing

nerve - sidecar for service registration

we can’t cover them all …

Registration

Embedded In-app registrationSidecar based approach

⊖ • more difficult to take

service lifecycle into account

⊕ • no impact on the

application • language agnostic • easier to control service

registration

⊖ • requires language

specific integration • will not work with

legacy services

⊕ • deep integration with

insight in the service lifecycle

Discovery

API basedDNS

⊖ • TTL difficulties • complex routing

requires tighter integration

⊕ • legacy integration

⊖ • API integration has

impact on the application

⊕ • service metadata can be

leveraged for routing

API Gateway & Routing

Hides partitioning of microservices

Single point of entry

Client-tailored API

Request aggregationfor performance

Simplifies clientsby aggregation of APIs

Increased complexity

Increased response time by network hop

Surgical Routing

Stress Testing

Canary Testing

Authentication

Authorization

Choosing origin servers

Logging debug info

Adding headers

Gathering statistics and metrics

Filter error handling

Generate static responses

Load Shedding

Dynamic behaviour change

…

Architect for Failure

Deployment

from CI to CD

Continuous Integration Infrastructure

build

Source Control System

Monolithic Build

single version tree

/preference-service /ordering-service /inventory-service …

Repositorypreference-service-

artefact-311

preference-service-artefact-311




own version tree

/preference-service

Repository

/ordering-service

Repository

/inventory-service

Repository

MicroService Build preference-service-artefact-765

preference-service-artefact-311MicroService Build

preference-service-artefact-459MicroService Build





deployment contextHandover environment specific technology specific application specific





deployment contextHandover

Automated installation scripts

⊖ execution time lots of scripts with small delta’s

⊕ transaction cost goes down repeatable deployments

Machine image with backed in microservice as build artefact





HandoverMachine image with backed in microservice as build artefact

VM Image

⊖ overhead of machine VM based deployment

⊕ speed of deployment

Containers with backed in microservice as build artefact

Compute, Storage, Network

Host OS

Hypervisor

VM1

MicroService

Guest OS

JVM

VM’s abstract underlying hardware, but limits resource utilisation

VM2

MicroService

Guest OS

JVM

• Isolation

• namespace

• pid mnt net uts ipc user

• resource usage

• (CPU, memory, disk I/O, etc.)

• Limited impact on Performance -

• http://ibm.co/V55Otq

• Daemon and CLI


Host OS

container1

container2

container3

container4

JVM JVM JVM

MicroService MicroService MicroService

JVM

MicroService

Containers have own isolated resources

http://ibm.co/V55Otq

/preference-service

Repository

DockerFile


Container Image Repository


Host OS

daemon

container1

JVM

MicroService

pull

push

build

provision

container1

JVM

MicroService


Container Image


Patterns

Container Image


Blue Green

Content Based Router

Blue/Green deployments

Container Image


Container Image


production traffictest traffic

Container Image


Stage 1 Stage 2 Stage 3

Content Based Router

Canary staged deployment

Zipkin + Sleuth heavily borrowing from Dapper & HTrace

CollectD & StatsD

Roll Your Own

https://github.com/DennisJaamann/micro-services-gui/tree/dev

https://github.com/DennisJaamann/micro-services-gui/tree/dev

What about DynaTrace?

- Correct Functional decomposition is crucial - reflect it in a organisational structure (💡Conway’s law)

- Getting it right is not guaranteed to be easy - your aiming for a very high standard in software delivery - balance the needs (advantages) with the costs (tradeoffs)

- take a simple step at a time

Conclusion

Are they here to stay?who can tell? but the monolith is dead