1. Tom De Wolf
Technical Lead
tom.dewolf@aca-it.be
Stijn Van den Enden
CTO
stijn.vandenenden@aca-it.be
www.aca-it.be
Thomas Borghs
Solution Engineer
thomas.borghs@aca-it.be
MICRO SERVICES
Yet another architectural style?
2. Concepts - What are Micro services?
Patterns - How to solve the challenges?
Technology - Using what?
3. 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.
!
Martin Fowler
4. 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
5. 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
6. business platform
Microservices
architect a single application as a set of services
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 }
7. 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
11. WHY - THE CURSE OF THE MONOLITH
App Server
WAR/EAR
Ordering
Inventory
Billing
UI
Large Code Intimidates Developers
Hard to understand
and modify
Development
slows down
Overloaded IDE
Overloaded
web container
12. WHY - THE CURSE OF THE MONOLITH
Small Change - Big Impact
Any change requires
full rebuild, test and deploy
Impact analysis
is huge effort and takes long
Obstacle for frequent
changes and deployments
App Server
WAR/EAR
Ordering
Inventory
Billing
UI
13. WHY - THE CURSE OF THE MONOLITH
Big Risk for Re-Write
App Server
WAR/EAR
Ordering
Inventory
Billing
UI
No hard module boundaries
quality and modularity breaks down over time
this enforces eventual need for re-write
Re-write = complete re-write
no partial re-write
Long term commitment to technology stack
change or try-out new technology implies re-write
14. WHY - THE CURSE OF THE MONOLITH
App Server
WAR/EAR
Ordering
Inventory
Billing
UI
Failure in monolith
brings it down
Little Resilience to Failure
15. WHY - THE CURSE OF THE MONOLITH
App Server
WAR/EAR
Ordering
Inventory
Billing
UI
Mostly Horizontal scaling
many load balanced instances
Scaling
can be difficult
Hard to scale to data growth
cope with all data
Different components
have different resource needs
Scaling development
implies coordination overhead
16. WHY - TYPES OF SCALING
App Server
WAR/EAR
Ordering
Inventory
Billing
UI
Database
All data
App Server
WAR/EAR
Ordering
Inventory
Billing
UI
App Server
WAR/EAR
Ordering
Inventory
Billing
UI
Horizontal Scaling
(monolith)
Vertical Scaling
App Server
WAR/EAR
Ordering
Inventory
Billing
UI
App Server
WAR/EAR
Ordering
Inventory
Billing
UI
Database
All data
(monolith)
Data Scaling
App Server
WAR/EAR
Ordering
Inventory
Billing
UI
Database
segment
App Server
WAR/EAR
Ordering
Inventory
Billing
UI
App Server
WAR/EAR
Ordering
Inventory
Billing
UI
Database
segment
Database
segment
(monolith)
18. • Small and focussed on 1 capability
• easier to understand
• IDE and deployment faster for 1 service
• Independent
• Release and deployment
• Scaling
• Development
• Loosely Coupled
• through lightweight communication
• Fault Isolation vs bring all down.
• Allows try-out of new technologies.
• Re-write can be limited to 1 service
• Impact Analysis stops at boundary
• Provide firm module boundaries with
explicit interface!
• Less risk on re-write
• Harder to violate boundary in development
• Decentralised choreography
• vs central orchestration
• vs central point of failure
• Decentralised data
• polyglot persistence
WHY - ARCHITECTURAL BENEFITS
19. WHY - EVOLUTIONARY ARCHITECTURE
1 - Key (business) drivers guide architectural decisions
2 - Postpone decisions to Last Responsible Moment
3 - Architect and develop for Evolvability
Micro-services are organised around business capabilities
Micro-services allow delay of scaling and technological decisions
Micro-services support evolution in technology, scaling, and features
23. Functional decomposition of the business domain
Software Design Customer Satisfaction
Separation of Concerns
Low Coupling, High Cohesion
Reduce Impact by
Encapsulating Source of Change
Predictable Cost of Change
Changes are Business Driven
Source of Change = Business
Functional Modularisation
24. B A
B
A
Functional decomposition of the business domain
• Change A impacts all modules = costly
• Change B requires split of module = costly
• Change A only impacts other module if api change
• Change B limited to module
25. side note: Domain Driven Design
“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.”
From: Domain Driven Design by Eric Evans.
Tackling complexity by abstracting the business domain concepts and logic into a
domain model and using this as a base for software development
26. 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
28. Functional decomposition of the business domain
AccountingInventory
BillingOrdering
customer
Invoice
balance
order
item
item
stock order
order
item
incoming cash
outgoing cash
stock
31. 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
32. 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
Side note: Conway’s Law
33. Side note: Conway's Law
Technology-based Team Composition Functional Team Composition
Ordering
InventoryBilling
Accounting
Container
Ordering
Container
Billing
Container
Inventory
Container
Accounting
UI
UI
34. Leads to higher coupling between services
PITFALL:
Incorrect functional decomposition
- harder to functionally scale the application
- errors will propagate through multiple services
- graceful degradation will be harder to achieve
- team development overhead
- T-scaling becomes harder
- large communicational overhead between services
- large overhead in releasing/deploying business features
- refactoring to correct decomposition is costly
most of the microservices architectural benefits are lost
35. PITFALL:
Incorrect functional decomposition
Safer to start with a functionally well decomposed monolith
and evolve it to a microservices architecture when the need arises
- rewriting failure scenario’s
- decentralised data
- service contract redesign
Refactoring the initial functional decomposition will be easier in a monolith
36. Approach - Key to success
Challenges - And ways to overcome them
37. - Keep Releases and deployments manageable
- high level of automation is needed
- Service monitoring is required
- Configuration management becomes more complex
CHALLENGE #1:
Operational Complexity
Complex Runtime: many moving parts
38. - distributed architectural properties to consider:
- decentralised data
- communication between services
- handling failures of components
- testing effort becomes greater
CHALLENGE #2:
Distributed Development
Services are deployed on multiple instances
39. Decentralised data
Each service has its own database - loose coupling
Might even be in another database technology
Data duplication between services might be required to ensure loose coupling
When implementing use cases spanning multiple services:
distributed transactions vs eventual consistency
40. Distributed Transactions vs Eventual Consistency
DISTRIBUTED TRANSACTIONS
- data is always consistent
!
- reduces system availability
- services are more tightly coupled
- has fallen out of favor in modern stacks (REST, NoSQL)
41. Distributed Transactions vs Eventual Consistency
EVENT-DRIVEN ASYNCHRONOUS UPDATES
- use a message broker to publish use cases to other services
- decouples producers and consumers (services) of events
- improves availability
- tradeoff between availability and data consistenty
- application needs to be able to handle eventually consistent data
42. Communication between services
Use cases can span multiple services
What type of communication is best used to implement such a use case?
Network properties need to be taken into account
43. What type of Communication?
SYNCHRONOUS HTTP-BASED
- easy
- firewall-friendly, works across the internet
!
- doesn’t support publisher-subscriber patterns
- client and server must both be available simultaneously
- client needs to know host and port of server
44. What type of Communication?
ASYNCHRONOUS NON-BLOCKING
- Client doesn’t block calling thread
- allows for parallelism
!
- client and server still must both be available simultaneously
- client still needs to know host and port of server
45. What type of Communication?
ASYNCHRONOUS MESSAGING
- For example through a Broker
- decouples message producers from consumers
- broker can buffer messages
- supports a variety of communication patterns
!
- broker is another moving part
- adds complexity
- request-reply communication pattern is not a natural fit
46. What type of Communication?
Accounting ServiceInventory Service
Billing ServiceOrdering Service
Use case: New Order Received
New order Create invoice
Update Incoming CashflowUpdate Stock
51. - communication between services is reduced
- when functional decomposition is done right
- when service size isn’t too small
- reduce communication between clients and Services with an API gateway
- executing service calls in parallel reduces impact of communication overhead
- reduce unneeded network usage by using circuit breakers
CHALLENGE #3
Minimising Communicational Overhead
Avoid Chatty Communication
52. Minimising Communicational Overhead
API GATEWAY
Ordering
Inventory
Billing
Accounting
Monolith Micro Services
Container
Ordering
Container
Inventory
Container
Billing
Container
Accounting
Desktop client
Mobile client
Desktop client
Mobile client
53. Minimising Communicational Overhead
API GATEWAY
Container
Ordering
Container
Inventory
Container
Billing
Container
Accounting
Desktop client
Mobile client
Api gateway
54. Handling Failures in Communication
CIRCUIT BREAKER
- Wrap a protected function in a circuit breaker
- Monitor protected function for failures
- The circuit breaks when a predefined threshold of fails is reached
- All future calls to the function go to fallback until the circuit is restored
55. Handling Failures in Communication
CIRCUIT BREAKER
Ordering Service Billing Service
new order received
Circuit breaker
Threshold = 10
Fallback queue
64. Compute, Storage, Network
Host OS
Hypervisor
VM1 VM2
MicroService MicroService
Guest OS
JVM
Guest OS
JVM
VM’s abstract underlying
hardware, but limit
resource utilisation
Compute, Storage, Network
Host OS
container1
container2
container3
container4
JVM JVM JVM
MicroService MicroService MicroService
JVM
MicroService
Containers have own
isolated resources
65.
66. Static website Web frontendUser DB Queue Analytics DB
Developmen
t VM
QA server Public Cloud Contributor’s
laptop
DOCKER IS A SHIPPING CONTAINER SYSTEM FOR CODEMultiplicityofStacks
Multiplicityof
hardware
environments
Production
Cluster
Customer Data
Center
Doservicesand
appsinteract
appropriately?
CanImigrate
smoothlyand
quickly
…that can be manipulated using
standard operations and run
consistently on virtually any
hardware platform
An engine that enables any
payload to be encapsulated
as a lightweight, portable,
self-sufficient container…
67. Static website Web frontendUser DB Queue Analytics DB
Developmen
t VM
QA server Public Cloud Contributor’s
laptop
DOCKER IS A SHIPPING CONTAINER SYSTEM FOR CODEMultiplicityofStacks
Multiplicityof
hardware
environments
Production
Cluster
Customer Data
Center
Doservicesand
appsinteract
appropriately?
CanImigrate
smoothlyand
quickly
Operator: Configure Once, Run
Anything
Developer: Build Once, Run
Anywhere
68. Static website
Web frontend
Background workers
User DB
Analytics DB
Queue
Development
VM
QA Server
Single Prod
Server
Onsite Cluster Public Cloud
Contributor’s
laptop
Customer
Servers
DOCKER SOLVES THE NXN PROBLEM
69. • 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
72. Compute, Storage, Network
Host OS
Hypervisor
VM1 VM2
MicroService MicroService
Guest OS
JVM
Guest OS
JVM
Compute, Storage, Network
Host OS
container1
container2
container3
container4
JVM JVM JVM
MicroService MicroService MicroService
JVM
MicroService
VM’s abstract underlying
hardware, but limit
resource utilisation
Containers have own
isolated resources
OSGi Runtime
JVM
MicroService
Compute, Storage, Network
Host OS
MicroService MicroService
Microservice run in their
own isolated classloader
and standbox in the JVM
74. 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
75. 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
76.
77.
78. The Story
* based on Functional Programming the Netflix API - Ben Christensen
79. Netflix API
Dependency A
Dependency D
Dependency G
Dependency J
Dependency M
Dependency P
Dependency B
Dependency E
Dependency H
Dependency K
Dependency N
Dependency Q
Dependency C
Dependency F
Dependency I
Dependency L
Dependency O
Dependency R
* based on Functional Programming the Netflix API - Ben Christensen
80. Discovery of Rx began with a re-architecture ...
* based on Functional Programming the Netflix API - Ben Christensen
81. ... that collapsed network traffic into coarse API calls ...
* based on Functional Programming the Netflix API - Ben Christensen
91. - Correct Functional decomposition is crucial
- reflect it in a organisational structure (Conway’s law)
- pretty hard to get right from the start
- A modular system can evolve to microservices
- balance the needs (advantages) with the costs (tradeoffs)
Conclusion
Are they here to stay?
who can tell?
but the monolith is dead