Microservices are a true hype these days. Netflix, Amazon, eBay, … are all using microservices, but why? The idea is simple; split your application into multiple services which can evolve autonomously through time. The name suggests to keep these services small. Conceptually this seems not all that different from a classical Service Oriented Architecture (SOA). Nonetheless, microservices do offer a new perspective. A monolithic application is divided into a couple small services which can be independently developed, deployed and scaled. Flexibility is increased, but using this model also has some pitfalls.This session sheds a light on the microservices landscape; the key drivers for using the pattern, tooling to support development and maintenance, and the pros and cons that go with it. We’ll also introduce some key design principles that can be used in creating and modelling these modular enterprise applications.

1. Microservices
Hitchhiker’s guide to cloud native applications
Andreas Evers
@andreasevers
Stijn Van den Enden
@stieno

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

3. Characteristics of a
Microservice style

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

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

6. • Independent
• Release and deployment
• Scaling
• Development

7. • Loosely Coupled
• through lightweight communication

8. • Fault Isolation vs. bring all down.

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

10. • Allows try-out of new technologies.
• Re-write can be limited to 1 service
• Impact Analysis stops at boundary

11. • Decentralised data
• polyglot persistence

12. Strong Module Boundaries Distribution
Eventual Consistency
Independent Deployment
Operational Complexity
Technology Diversity
Security Segmentation
Separate Scale-out
Parallel Development

13. Is this any different from SOA?

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

15. Classic SOA
integrates different applications as a set of services
Enterprise Service Bus
WS* WS* WS* WS* WS*
WS* WS* WS* WS* WS*
Workflow Engine
Intelligence
Orchestration

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

17. 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
ESB
WS*/SOAP
Orchestration
License-driven
Target problem:
Integrate (Legacy) Software
Intelligent Communication Layer
Light-weight
HTTP/REST/JSON
Choreography
Target problem:
Architect new Business Platform
Dumb Communication Layer
Intelligent Services

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

19. side note: Domain Driven Design
Tackling 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

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

21. AccountingInventory
BillingOrdering
Functional decomposition of the business domain

22. Functional decomposition of the business domain
AccountingInventory
BillingOrdering
customer
Invoice
balance
order
item
item
stock order
order
item
incoming cash
outgoing cash
stock

23. Benefits of functional decomposition

24. AccountingInventory
BillingOrdering
customer
Invoice
balance
order
item
item
stock order
order
item
incoming cash
outgoing cash
stock
Benefits of functional decomposition

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

26. take
notice.

27. 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!”

28. What do we need to get
started?

29. Implementing a Microservice

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

31. Service Discovery

32. NodeClient
Node
Node
Node
Node
?
Loadbalancer
Single Point of Failure
Manual configuration management

33. Client
Node
Node
Node
Node
?
Registry
register
health
lookup
Node
🚫
unregister

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

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

36. A HashiCorp Project.
https://www.consul.io/
K/V
K/V
K/V
K/V
K/V
Distributed Key/Value Store
http
dns
Client
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)

37. 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
MicroService
register
renew
get registry
eureka
ribbon
https://github.com/Netflix/eureka
https://github.com/Netflix/ribbon

38. Apache ZooKeeper™
synapse - HAProxy based service discovery/routing
nerve - sidecar for service registration
we can’t cover them all …

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

40. API Gateway & Routing

42. Hides partitioning
of microservices
Single point of entry
Client-tailored API
Request aggregation
for performance
Simplifies clients
by aggregation of APIs
Increased complexity
Increased response time
by network hop

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

46. Architect for Failure

52. Deployment

53. from CI to CD

54. Continuous Integration
Infrastructure
build
Source Control System
Monolithic Build
single
version tree
/preference-service
/ordering-service
/inventory-service
…
Repository
preference-service-
artefact-311
preference-service-
artefact-311
preference-service-
artefact-311

55. 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-311
MicroService Build
preference-service-
artefact-459MicroService Build

56. preference-service-
artefact-765
preference-service-
artefact-311
preference-service-
artefact-459
preference-service-
artefact-765
deployment contextHandover environment specific
technology specific
application specific

57. preference-service-
artefact-765
preference-service-
artefact-311
preference-service-
artefact-459
preference-service-
artefact-765
deployment context
Handover
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

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

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

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

61. Container Image
preference-service-
artefact-765

63. Patterns

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

65. Container Image
preference-service-
artefact-765
Stage 1 Stage 2 Stage 3
Content Based Router
Canary staged deployment

71. Zipkin + Sleuth heavily borrowing from Dapper & HTrace

72. CollectD & StatsD

81. Roll Your Own
https://github.com/DennisJaamann/micro-services-gui/tree/dev

82. What about DynaTrace?

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