This document discusses microservices and distributed systems. It notes that microservices involve small, isolated components with clear responsibilities. It provides examples of how services like inventory, payment, and shipping could work together using messages and events. The document discusses challenges like asynchronous collaboration, distributed transactions, and handling things like timeouts and retries in a distributed environment. It also discusses approaches like orchestration and choreography for coordinating services and processes across microservice boundaries.
12. It is not SOA
InventoryPayment ShippingCheckout
Bus
Order
Placed
Does not
know
recepient
Does not
know
sender
Event: Fact that
happened in the past,
Immutable fact,
0..n recepients
Order
Placed
Smart endpoints
and dumb pipes
15. Service A
Challenge: Asynchronous collaboration
Send
message
to B
Service B
Wait for
response
Timeout handling
Message correlation &
deduplication
State handling
Parallelism & merging
16. Challenge: Distributed transactions
1. book
hotel
2. book
car
3. book
flight
6.
cancel
hotel
5.
cancel
car
4. In case of
failure trigger
compensations
book
trip
Service A
Car ServiceHotel Service Flight Service
ACID-Transactions
only local in the
service contexts
Distributed
transaction via Saga
pattern using
compensating
activities
20. Toolbox for distributed systems
Handling of time &
timeouts
Retry
Versioning
Compensation & Saga
Message correlation &
deduplication
Performance &
scalability
21. The microservice community
*Picture randomly taken from http://wareflo.com/2016/11/from-apis-to-microservices-workflow-orchestration-and-choreography-across-healthcare-organizations/. Not connected to statements on slide.
Orchestration…
…introduces single point of
failure…
…leads to god services…
…leads to tight coupling…
„
23. End-to-end processes using eventflows?
InventoryPayment ShippingShop
Order
placed
Payment
received
Goods
fetched
Goods
shipped
24. Commanding is important
InventoryPaymentOrder ShippingShop
Bus
Order
Placed
Event: Fact that
happened in the past,
Immutable fact,
0..n recepients
Order
Placed
Command: Intend,
1 recipient.
Coupling the other
way round
Retrieve
Payment
Fetch
Goods
Ship
Goods
Problems:
re-ordering of services?
New requirements & 3-legged-race
..
Missing:
Point where to change things
No visibility of current state (probably done vaguely with Tracing)
Vielleicht in der Design-Phase mal aufmalen
Das kann nen fachlichen Wert haben! Wir sollten es aber so vielleicht nicht ausführen.
Aber zum verstehen ist es cool.
Aber in der Realisierung!
A process should not be bound to organziational structure.
Separation of concerns
Focus of single services
Divide and conquer
A process should not be bound to organziational structure.
There is some homework to do here – but we have it on the radar
Hier sollten wir als BPM aufholen und uns Gedanken machen
Da gibt es viel zu liefern & zu lernen – da wird viel passieren
Ich hab ein einfaches Beispiel ne kollab mit bpmn.io aus distributed orchestration zusammen anzuzeigen. Das geht evtl. einfach.
Im Betrieb & Verbesserung also wieder zusammen bringen – da wird es spannend
Demo verfügbar
Microservices most prbably will happen
Executable BPMN processes help to implement services within distributed systems
End-to-end processes are 1st class citizens, but composed out of pieces fitting the (microservice) boundaries
This is not black / white. There is no all-in decision necessary. …
Aber events sind großartig. Nicht nur technisch scale auch natürlicher. Fachlich einfacher
Bpmn potentiell vor allem Ausführungssprache! BizDevOps.
Do not overrate roundtrip.
A lot of systems will be event- but also domain-driven microservices in future
End-to-end processes must respect responsibility and ownership and be sliced into appropriate pieces. Use distributed orchestration instead of monolithic BPM
BPMN can keep on serving as great executable flow language – yeah!
The challenges for services collaboration (the „between the services“) will increase, workflow technology can be a great help here.
https://www.thoughtworks.com/insights/blog/building-reliable-digital-operations
Think about a new function that just does XXX when event YYY occurs -> go for it!
This is not black / white. There is no all-in decision necessary. …
But it seems not to really improve – developers are still afraid of „BPM“
Time to introduce a new word for it!
Developer friendly even morre consequent as in the past: Ployglot, XAML & JSON, focus on concrete developer problems at hand, …
Composable: not only Java with e.g. Spring Boot, but also within Go and other
nicht nur das tecki Lager lehnt es ab
Scheinbar müssen wir was besser machen / können was lernen)