Event-Driven Microservices, the Sense, the Non-sense and a Way Forward - Allard Buijze (https://www.youtube.com/watch?v=jrbWIS7BH70)
Why microservices
monolith that is well-structured, can scale as well
What goes in one service? What goes in another?
order customer product inventory
Are you micro-pile-of-shit?
- redeploy multiple services at one
- strong dependencies on other service before you can do something
“just go up, and then go right”
anti-modularity forces
suit & tie telling you “the deadline shifted”
technical debt
"""
it’s all about discipline
if you can’t wax a car, forget about karate
If you can’t build a monolith, forget about microservices
"""
there is a journey towards microservices
- build monolith
- compnents
- split off services => non-functional requirements
assume components are not on the same deployment
inverted
“if all you have is a hammer, everything looks like a nail”
event patterns
event notification: “something changed”
event-carried state transfer: “this changed”
event sourcing: everything becomes an event
duplicate logic
item is ordered if added, not removed, then ordered
event: explain something happened
command: intent to change something
queries: need for information
=> event notification
!= just save all the events
event handling
Event sourcing check: throw away everything, except your eventstore
storage is cheap
everything is complex at first
forget about state, think about behavior
“if all you have is a hammer, everything looks like a nail”
:) can I do this one change?
:( “give me all orders above 100$”
:) can I do this one change?
:) “give me all orders above 100$”
events -> contracts with unknown services
consumer driven contracts
within context, want details
across borders, high level
assign services to bounded context
anti corruption layer
use them as explicitly as events
monolith first
disciplined modules
split off services