Microservices Hitchhiker’s guide to cloud native applications Andreas Evers @andreasevers Stijn Van den Enden @stieno
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
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
Characteristics of a Microservice style
• 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
Classic SOA integrates different applications 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
Microservices architect a single application 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 }
Classic SOA integrates different applications as a set of services
Microservices architect a single application as a set of services
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
preference-service-artefact-311
Continuous Integration Infrastructure
Source Control System
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
preference-service-artefact-765
preference-service-artefact-311
preference-service-artefact-459
preference-service-artefact-765
deployment contextHandover environment specific technology specific application specific
preference-service-artefact-765
preference-service-artefact-311
preference-service-artefact-459
preference-service-artefact-765
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
preference-service-artefact-765
preference-service-artefact-311
preference-service-artefact-459
preference-service-artefact-765
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
Compute, Storage, Network
Host OS
container1
container2
container3
container4
JVM JVM JVM
MicroService MicroService MicroService
JVM
MicroService
Containers have own isolated resources
/preference-service
Repository
DockerFile
Continuous Integration Infrastructure
Container Image Repository
Compute, Storage, Network
Host OS
daemon
container1
JVM
MicroService
pull
push
build
provision
container1
JVM
MicroService
Source Control System
Container Image
preference-service-artefact-765
Patterns
Container Image
preference-service-artefact-765
Blue Green
Content Based Router
Blue/Green deployments
Container Image
preference-service-artefact-765
Container Image
preference-service-artefact-123
production traffictest traffic
Container Image
preference-service-artefact-765
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
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