SLIDE 1
@allardbz
Event Driven Microservices
The sense, the non-sense and a way forward
@allardbz
Event Driven Microservices The sense, the non-sense and a way - - PowerPoint PPT Presentation
Event Driven Microservices The sense, the non-sense and a way - - PowerPoint PPT Presentation
Event Driven Microservices The sense, the non-sense and a way forward @allardbz Once upon a time @allardbz Universal BBC architecture Box Box Cylinder Source: Ted Neward @allardbz Source:
SLIDE 2
SLIDE 3
@allardbz
“Universal ‘BBC’ architecture”
Box Box Cylinder
Source: Ted Neward
SLIDE 4
@allardbz
Source: http://www.sabisabi.com/images/DungBeetle-on-dung.JPG
SLIDE 5
@allardbz
Microservices to the rescue!
SLIDE 6
@allardbz
Why microservices?
SLIDE 7
@allardbz
Agility (Team) Scalabilty
SLIDE 8
@allardbz
Agility Scalability Additional Complexity
SLIDE 9
@allardbz
“Universal Microservices architecture”
SLIDE 10
@allardbz
Noun Driven Design
Noun? → Service!
SLIDE 11
@allardbz
Noun Driven Design
OrderService
SLIDE 12
@allardbz
Noun Driven Design
CustomerService
SLIDE 13
@allardbz
Noun Driven Design
ProductService
SLIDE 14
@allardbz
Noun Driven Design
InventoryService
SLIDE 15
@allardbz
Number of deployment units Modularity
“Evil anti-modularity forces”
SLIDE 16
@allardbz
SLIDE 17
@allardbz
Want to build microservices? Learn to build a decent monolith first!
SLIDE 18
@allardbz
$
SLIDE 19
@allardbz
Location transparency
A Component should not be aware, nor make any assumptions, of the location of Components it interacts with
A component should neither be aware of nor make any assumptions about the location of components it interacts with. Location transparency starts with good API design
(but doesn’t end there)
SLIDE 20
@allardbz
Events
SLIDE 21
@allardbz
Service C Service B Service D Service A
SLIDE 22
@allardbz
Service A Service C Service B Service D
Event
SLIDE 23
@allardbz
“Event” all the things!
SLIDE 24
@allardbz
Maslow’s Hammer
SLIDE 25
@allardbz
Birmingham Screwdriver
SLIDE 26
@allardbz
“Maslow Syndrome”
SLIDE 27
@allardbz
Event-carried State Transfer Event Notification Event Sourcing
SLIDE 28
@allardbz
‘Event-Driven’ Microservices
Need to know
- rdered items
Order service OrderCreated → ItemAdded → ItemRemoved → OrderConfirmed →
SLIDE 29
@allardbz
Or worse…
Shipping Service Order service OrderCreated → InventoryConfirmed ReadyForShipping → OrderShipped Payment service OrderPaid → ReadyForPayment
SLIDE 30
@allardbz
Microservices Messaging
Commands Events Queries
Route to single handler Use consistent hashing Provides confirmation/result Distribute to all logical handlers Consumers express ordering req’s No results Route with load balancing Sometimes scatter/gather Provides result
"Event" and “Message" is not the same thing
SLIDE 31
@allardbz
OrderConfirmed →
‘Event-Driven’ Microservices
Need to know
- rdered items
Order service ItemAdded → ItemRemoved → OrderConfirmed → OrderCreated → GetOrderDetails OrderDetails →
SLIDE 32
@allardbz
Event Sourcing: the truth, the whole truth, nothing but the truth
SLIDE 33
@allardbz
State storage Event Sourcing
Event Sourcing
id: 123 items 1x Deluxe Chair - € 399 status: return shipment rcvd OrderCreated (id: 123) ItemAdded (2x Deluxe Chair, €399) ItemRemoved (1x Deluxe Chair, €399) OrderConfirmed OrderShipped OrderCancelledByUser ReturnShipmentReceived
SLIDE 34
@allardbz
Event Sourcing
Some smart analytics Order service OrderCreated → ItemAdded → ItemRemoved → OrderConfirmed →
SLIDE 35
@allardbz
Business reasons Technical reasons
Why use event sourcing?
- Auditing / compliance /
transparency
- Data mining, analytics:
value from data
- Guaranteed completeness of raised
events
- Single source of truth
- Concurrency / conflict resolution
- Facilitates debugging
- Replay into new read models (CQRS)
- Easily capture intent
- Deal with complexity in models
SLIDE 36
@allardbz
The challenges
Dealing with increasing storage size Complex to implement “Event Thinking”
SLIDE 37
@allardbz
“Event” all the things! Source
SLIDE 38
@allardbz
Event store in context
Application Event store
Past events New events
- Works well for processing changes on single
entities/aggregates (Commands)
- Does not work well for generic queries
SLIDE 39
@allardbz
CQRS
Command-Query Responsibility Segregation
Command Handler Event store
Past events New events
Projection database Query Handler
New events
Projection logic
Updates Selection criteria Data
SLIDE 40
@allardbz
“CQRS” all the things?
SLIDE 41
@allardbz
Service Service Service Service Service Service
SLIDE 42
@allardbz
Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service
SLIDE 43
@allardbz
Communication = Contract
SLIDE 44
@allardbz
Service Service Service Service Service
SLIDE 45
@allardbz
Bounded context
Explicitly define the context within which a model applies. Explicitly set boundaries in terms of team organization, usage within specific parts of the application, and physical manifestations such as code bases and database schemas. Keep the model strictly consistent within these bounds, but don’t be distracted or confused by issues outside.
SLIDE 46
@allardbz
Service Service Service Service Service Service Service Service
SLIDE 47
@allardbz
Service Service Service Service Anti-corruption layer Service
SLIDE 48
@allardbz
SLIDE 49
@allardbz
In closing….
SLIDE 50
@allardbz
Consider commands and queries as much as events
SLIDE 51
@allardbz
Sharing is caring
SLIDE 52
@allardbz
Beware coupling across bounded contexts
SLIDE 53
@allardbz
“Microservice Journey”
SLIDE 54
@allardbz
Monolith first
SLIDE 55
@allardbz