Microservices richtig umgesetzt bedeutet auch die ehemals monolithische Datenbank aufzusplittern. Transaktionen über Servicegrenzen hinweg, stellen somit eine neue Herausforderung dar.

1. #WISSENTEILEN
Aus der Rubrik „Spaß mit Microservices“
Transaktionen
#WISSENTEILEN
Lars Röwekamp | @_openKnowledge | @mobileLarson

2. #WISSENTEILEN
ÜBER OPEN KNOWLEDGE
Branchenneutrale Softwareentwicklung & IT-Beratung

3. #WISSENTEILEN
ÜBER MICH
Wer bin ich - und wenn ja, wie viele?
• CIO New Technologies
• Enterprise & Mobile
• Autor, Speaker, Coach & Mentor
• Snowboard & MTB Enthusiast (a.k.a. “stets bemüht“)
Lars Röwekamp (a.k.a. @mobileLarson)

4. #WISSENTEILEN#WISSENTEILEN
Agenda:
Wo liegt das Problem?
Die Alternative a.k.a. „Plan B“
TX via SAGA Pattern

5. #WISSENTEILEN
Wo liegt das
Problem?

6. #WISSENTEILEN
Der fette
MONOLITH

7. #WISSENTEILEN

8. #WISSENTEILEN
Use-Case

9. #WISSENTEILEN
Use-Case

10. #WISSENTEILEN
Use-Case

11. #WISSENTEILEN
Hey, lasst uns Microservices machen …

12. #WISSENTEILEN
Lasst und zusammengehörige Logik finden.

13. #WISSENTEILEN
Und in „kleine“ Services zerlegen.

14. #WISSENTEILEN
Ups, das gilt natürlich auch für die DB!

15. #WISSENTEILEN
Database per Service Pattern

16. #WISSENTEILEN
Use-Case

17. #WISSENTEILEN
Use-Case

18. #WISSENTEILEN
Use-Case

19. #WISSENTEILEN
Das klappt nie im Leben!
(Anonymous, DB Admin)

20. #WISSENTEILEN
Wir brauchen Transaktionen!
(Anonymous, DB Admin)

21. #WISSENTEILEN#WISSENTEILEN
Die Alternative
a.k.a. „Plan B“

22. #WISSENTEILEN#WISSENTEILEN
„Benötigen wir wirklich eine
Transaktion oder gibt es einen
fachlich sinnvollen Plan B?“

23. #WISSENTEILEN
„Starbucks does not know
Two-Phase-Commit“
http://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html

24. #WISSENTEILEN
The Real World is
not transactional!

25. #WISSENTEILEN
The Online World is
not transactional!

26. #WISSENTEILEN

27. #WISSENTEILEN
Plan „B“
Strategies
Order
Service
Inventory
Service
#2

28. #WISSENTEILEN
Strategie #1
Lazy Evaluation

29. #WISSENTEILEN
Plan B - Strategy #1: Lazy Evaluation
a.k.a. die „es kommt, wie es kommt“ Strategie
• TX fachlich aufsplitten, sequentiell
durchführen und schauen, ob es klappt
• im Problemfall alternative Logik ausführen

30. #WISSENTEILEN
Lazy
Evaluation
Order
Service
Inventory
Service
#2

31. #WISSENTEILEN
Lazy
Evaluation
Order
Service
Inventory
Service
checkOut
#2

32. #WISSENTEILEN
Lazy
Evaluation
Order
Service
Inventory
Service
checkOut
#1
decrement

33. #WISSENTEILEN
Strategie #2
Beeing Optimistic

34. #WISSENTEILEN
Plan B - Strategy #2: Beeing Optimistic
a.k.a. die „es wird schon gutgehen“ Strategie
• wie “Lazy Evaluation“ nur mit erhöhter
Wahrscheinlichkeit, dass die „Transaktion“
erfolgreich abläuft.

35. #WISSENTEILEN
Beeing
Optimistic
Order
Service
Inventory
Service
#2
#4
least known value
of items available:

36. #WISSENTEILEN
Beeing
Optimistic
Order
Service
Inventory
Service
checkOut
#2
#4
least known value
of items available:

37. #WISSENTEILEN
Beeing
Optimistic
Order
Service
Inventory
Service
checkOut
#1
decrement
#1
least known value
of items available:

38. #WISSENTEILEN
Strategie #3
Safeguard

39. #WISSENTEILEN
Plan B - Strategy #3: Safeguard
a.k.a. die „frag besser nochmal nach“ Strategie
• wie “Beeing Optimistic“ nur auf Basis von
„nearly Real-Time“ Daten

40. #WISSENTEILEN
Optimistic
w/ Safeguard
Order
Service
Inventory
Service
#2
#4
least known value
of items available:

41. #WISSENTEILEN
Optimistic
w/ Safeguard
Order
Service
Inventory
Service
checkOut
#2
#4
least known value
of items available:

42. #WISSENTEILEN
Optimistic
w/ Safeguard
Order
Service
Inventory
Service
checkOut
#2
inventory?
#4
least known value
of items available:

43. #WISSENTEILEN
Optimistic
w/ Safeguard
Order
Service
Inventory
Service
checkOut
#2
2 items left!
#2
least known value
of items available:

44. #WISSENTEILEN
Optimistic
w/ Safeguard
Order
Service
Inventory
Service
checkOut
#1
decrement
#1
least known value
of items available:

45. #WISSENTEILEN
Strategie #4
Plan „B“

46. #WISSENTEILEN
Order
Service
Inventory
Service
#0
Good to have
a Plan „B“
#1
least known value
of items available:

47. #WISSENTEILEN
Good to have
a Plan „B“
Order
Service
Inventory
Service
#0
checkOut
#1
least known value
of items available:

48. #WISSENTEILEN
Good to have
a Plan „B“
Order
Service
Inventory
Service
#0
checkOut
#1
least known value
of items available:
„Ist der
Datenstand
konsistent?“

49. #WISSENTEILEN
Good to have
a Plan „B“
Order
Service
Inventory
Service
#0
checkOut
#1
least known value
of items available:
„Kann ich
pünktlich
liefern?“*
*„Und ist der Datenstand
letztendlich konsistent
(aka eventual consistency)?“

50. #WISSENTEILEN#WISSENTEILEN
Plan B? Schön & gut, aber ich
brauche meine Transaktionen!

51. #WISSENTEILEN#WISSENTEILEN
TX via
SAGA Pattern

52. #WISSENTEILEN
Microservices mit „eigenen“ Daten

53. #WISSENTEILEN
Fachliche TX über Servicegrenzen hinweg

54. #WISSENTEILEN
(Quelle: Microservices Pattern, Chris Richardson)

55. #WISSENTEILEN
(Quelle: Microservices Pattern, Chris Richardson)

56. #WISSENTEILEN
(Quelle: Microservices Pattern, Chris Richardson)
„Sichtbarkeit"
Order Service
„Sichtbarkeit“
Customer Service

57. #WISSENTEILEN
it‘s all about
consistency
- eventual -

58. #WISSENTEILEN
Wie garantiere ich die Konsistent der
Daten über Servicegrenzen hinweg?

59. #WISSENTEILEN
Strategie #1
überdenke die
Servicegrenzen

60. #WISSENTEILEN
Die
„Service“
Strategie

61. #WISSENTEILEN
Die
„Service“
Strategie

62. #WISSENTEILEN
Geänderte Servicegrenzen
• technologisch eine super Lösung, aber …
• Problem der Verantwortlichkeiten
• Problem Bounded Context / Domänen Modell
• Vorteile der Microservices gehen verloren
• „Big Ball of Mud“ lässt grüßen

63. #WISSENTEILEN
Strategie #2
XA mit 2PC

64. #WISSENTEILEN
Die
„XA“
Strategie

65. #WISSENTEILEN
Die
„XA“
Strategie
Btw: DB locks
Btw: Chatty O(4n)
mit Retries = (n^2)
Btw: CAP Theorem

66. #WISSENTEILEN
Verteilte Transaktionen via XA
• aus Developer-Sicht wie lokale TX, aber …
• Verlust der losen Kopplung, da synchrone IPC
• kein Support durch „moderne Plattformen“*
* Cloud-Komponenten, noSQL, MQs

67. #WISSENTEILEN
Strategie #3
DIY 2PC

68. #WISSENTEILEN
Die
„DIY 2PC“
Strategie*
*Nein, das willst du nicht. Glaube mir!

69. #WISSENTEILEN
Strategie #4
Business TX via
SAGA Pattern

70. #WISSENTEILEN
Quelle:
SAGAS, Hector Garcia-Molina
& Kenneth Salem, January 1987
Die
„Saga“
Strategie

71. #WISSENTEILEN
Verteilte Transaktionen via SAGAs
SAGA Idee:
Abbilden einer verteilten fachlichen
Transaktion durch eine Abfolge lokaler
technischer Transitionen / Transaktionen

72. #WISSENTEILEN
Verteilte Transaktionen via SAGAs

73. #WISSENTEILEN
Verteilte Transaktionen via SAGAs
• Konsistenz von Daten zwischen Services
wird durch eine wohldefinierte Abfolge lokaler
Transitionen/Transaktionen erreicht.
• Service kommuniziert „erfolgreiche“ lokale
Transition/Transaktion an den nächsten
beteiligten Service*.
*mehr dazu später

74. #WISSENTEILEN
Die
„Saga“
Strategie

75. #WISSENTEILEN
Die
„Saga“
Strategie

76. #WISSENTEILEN
Die
„Saga“
Strategie

77. #WISSENTEILEN
Die
„Saga“
Strategie

78. #WISSENTEILEN
Die
„Saga“
Strategie

79. #WISSENTEILEN
Die
„Saga“
Strategie

80. #WISSENTEILEN
Wow, that
is simple!
What can
go wrong?

81. #WISSENTEILEN
Die
„Saga“
Strategie

82. #WISSENTEILEN
Die
„Saga“
Strategie

83. #WISSENTEILEN
Die
„Saga“
Strategie
CA = Compensation Algorith a.k.a.
Compensation Transaction

84. #WISSENTEILEN
Die
„Saga“
Strategie
CA = Compensation Algorith a.k.a.
Compensation Transaction
„Every Ti has its Ci“

85. #WISSENTEILEN
Verteilte Transaktionen via SAGAs
• wohldefinierte Abfolge von Compensation
Algorithms realisieren verteiltes Rollback
• Compensation Algorithms sind fachlicher
Code und somit Applikationslogik
• Abfolge von lokalen TXs & CAs kann
beliebig komplex werden!

86. #WISSENTEILEN
Frage:
Wie koordiniert
man das Ganze?

87. #WISSENTEILEN
Steuerung von SAGAs
TX 1
TX 2
TX 3
TX 4
TX 5
TX 6
order = PENDING
item = PENDINGAPPORVED
APPORVED

88. #WISSENTEILEN
Steuerung von SAGAs
• Choreographie
• Orchestrierung

89. #WISSENTEILEN
Steuerung von SAGAs
• Choreographie
• Orchestrierung

90. #WISSENTEILEN
Choreographie von SAGAs
• implizite Sequenzsteuerung
• verteilte Koordination durch Eventfluss
• „Wissen“ liegt bei den beteiligten Services

91. #WISSENTEILEN
Saga via
Choreography

92. #WISSENTEILEN
Saga via
Choreography

93. #WISSENTEILEN
Saga via
Choreography

94. #WISSENTEILEN
Saga via
Choreography

95. #WISSENTEILEN
Saga via
Choreography

96. #WISSENTEILEN
Saga via
Choreography

97. #WISSENTEILEN
Choreographie von SAGAs
• pro
lose gekoppelt (Teilnehmer kennen sich nicht)
relativ einfach zu implementieren
• contra
i.d.R. zyklische Abhängigkeiten
erhöhte Komplexität im Domänen-Modell
kein zentraler Business-Code (wann valide?)

98. #WISSENTEILEN
Choreographie von SAGAs
• btw lose Kopplung
Teilnehmer kennen sich zwar nicht, wissen aber
genau, was bei einem Event zu tun ist und wie
im Anschluss – durch ein eigenes Event – zu
antworten ist (a.k.a. pseudo lose Kopplung)

99. #WISSENTEILEN
Steuerung von SAGAs
• Choreographie
• Orchestrierung

100. #WISSENTEILEN
Orchestrierung von SAGAs
• explizite Sequenzsteuerung
• zentraler SAGA-Koordinator im Service
• Command / Handler Pattern
• beteiligte Services haben kein „Wissen“

101. #WISSENTEILEN
Saga via Orchestration

102. #WISSENTEILEN
Saga via Orchestration

103. #WISSENTEILEN
Saga via Orchestration

104. #WISSENTEILEN
Saga via Orchestration

105. #WISSENTEILEN
Saga via Orchestration

106. #WISSENTEILEN
Saga via Orchestration

107. #WISSENTEILEN
Saga via Orchestration

108. #WISSENTEILEN
Saga via Orchestration

109. #WISSENTEILEN
Saga via Orchestration

110. #WISSENTEILEN
Saga via Orchestration

111. #WISSENTEILEN
Saga via Orchestration

112. #WISSENTEILEN
Orchestration von SAGAs
• pro
Logik ist einfach(er) zu verstehen
fachliche Kopplung nur unidirektional
keine zyklischen Abhängigkeiten
Separation of Concerns (Domain Logic vs. TX)

113. #WISSENTEILEN
Orchestration von SAGAs
• contra
„Smart Orchestrator & Dump Services“ Pattern,
d.h. Risiko, zu viel Business Logic im
Orchestrator zu zentralisieren

114. #WISSENTEILEN
Orchestration von SAGAs
• btw Orchestrator
Will man den wirklich selber bauen? Nein!
Alternative 1: Saga Framework
Alternative 2: Lightweight Workflow Engine

115. #WISSENTEILEN
Frage:
Und das kann
funktionieren?

116. #WISSENTEILEN
Konsistenz von Daten und Nachrichten
• Services veröffentlichen „Erfolgs“-Nachricht
direkt nach lokaler TX
• lokale TX und „Erfolgs“-Nachricht sind
atomare Einheit aus Sicht des Services
• garantierte Beendigung der Business TX*
*Message Broker buffered bei Bedarf die Message

117. #WISSENTEILEN
Konsistenz von Daten und Nachrichten

118. #WISSENTEILEN
Konsistenz von Daten und Nachrichten

119. #WISSENTEILEN
Konsistenz von Daten und Nachrichten

120. #WISSENTEILEN
Konsistenz von Daten und Nachrichten

121. #WISSENTEILEN
Konsistenz von Daten und Nachrichten

122. #WISSENTEILEN
Fehlende Isolation
• SAGA = ACD (ACID ohne Isolation)
• fehlende Isolation kann zu Anomalien führen
(lost updates, dirty reads, event race condition)
• Anomalien müssen soweit minimiert bzw.
verhindert werden, dass sie fachlich vertretbar
sind!

123. #WISSENTEILEN

124. #WISSENTEILEN
Überdenke deine
Prozesse

125. #WISSENTEILEN
Überdenke deine
Servicegrenzen

126. #WISSENTEILEN
Realisiere fachliche
Transaktionen

127. #WISSENTEILEN
Realisiere fachliche
Kompensationen

128. #WISSENTEILEN
Die Weisheit des Tages:
„Wenn deine Service-Landkarte
genauso aussieht, wie dein Monolith,
dann hattest du entweder vorher kein
Problem oder wirst zukünftig
eine Menge Probleme haben!“

129. #WISSENTEILEN
FRAGEN
? ? ?

130. #WISSENTEILEN
Kontakt
LARS RÖWEKAMP
CIO NEW TECHNOLOGIES
lars.roewekamp@openknowledge.de
+49 (0)441 4082 – 0
@mobileLarson
@_openknowledge
OFFENKUNDIGGUT

131. #WISSENTEILEN
Bildnachweise
#19 © vasakna – fotolia.com
#25 © rawpixel.com – shutterstock.com
#43 © vadymvdrobot – fotolia.com
#82 © pathdoc – shutterstock.com
#119 © garagestock – shutterstock.com
All other pictures inside this presentation orginate
from pixabay.com or were created by my own.