Die gute Nachricht vorweg: Einen einzelnen Microservice zu implementieren ist dank Bounded Context, loser Kopplung und klar definierter Kommunikationsschnittstellen denkbar einfach. Nur leider macht ein Frühling noch keinen Sommer und ein einzelner Microservice noch lange keine sinnvolle Anwendung aus! Um am Ende nicht im Chaos zu versinken, benötigt auch eine Microservices-basierte Anwendung eine Architektur und die Verwendung von Patterns. Wie zum Beispiel stellt man die Evolution von Schnittstellen sicher? Oder wie soll die UI eingebunden werden? Welche Aufgaben übernimmt ein API Gateway und wird es überhaupt benötigt? Sollten Microservices synchron oder asynchron kommunizieren? Oder gar beides? Fragen über Fragen, deren Klärung über Erfolg oder Misserfolg der eigenen Anwendung entscheiden kann. Der Workshop gibt einen Einblick in die verschiedenen Herausforderungen bei der Umsetzung einer Microservices-basierten Anwendung und diskutiert verschiedene Lösungsansätze, Patterns und Best Practices. Ein optimaler Einstieg in den Microservices-Summit.

1. #WISSENTEILEN
#WISSENTEILEN
Microservices
Architecture
Lars Röwekamp
CIO New Technologies
@mobileLarson
@_openknowledge

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)
LR

4. #WISSENTEILEN#WISSENTEILEN
Workshop Agenda:
Microservices DNA
Architektur & Pattern

5. #WISSENTEILEN
Microservices DNA

6. #WISSENTEILEN
DISCLAIMEREs folgt sehr viel Text. Und der ist auch noch „geklaut“!

7. #WISSENTEILEN
Wie groß ist klein
„A microservices ecosystem (ME) is a platform of
services each encapsulating a business capability.
Developers can build, test and release each
microservice independently.
ME enforces an organizational structure of
autonomous long standing teams, each
responsible for one or multiple services.“
(Zhamak Dehghani, ThoughtWorks)

8. #WISSENTEILEN
Functional
Decompensation

9. #WISSENTEILEN
Single
Responsibility
Principle

10. #WISSENTEILEN
Share nothing*
*a.k.a. share as little as possible

11. #WISSENTEILEN
Explicitly
published
Interfaces

12. #WISSENTEILEN
Lightweight
Communication

13. #WISSENTEILEN
Independently
deploy, upgrade
scale, replace

14. #WISSENTEILEN
Heterogeneous
a.k.a. Polyglot

15. #WISSENTEILEN
Bussiness
Focused

16. #WISSENTEILEN

17. #WISSENTEILEN
Easier
to develop, understand & maintain.

18. #WISSENTEILEN
Faster
start than a monolith

19. #WISSENTEILEN
Local changes
can be easily deployed

20. #WISSENTEILEN
Scaling
indepentent from all other services

21. #WISSENTEILEN
Fault isolation
improvement via own process

22. #WISSENTEILEN
Stack isolation
no long term commitment to any stack

23. #WISSENTEILEN
Agility
optimized „time to market“

24. #WISSENTEILEN
vs.

25. #WISSENTEILEN
In der Theorie
ist alles ganz einfach

26. #WISSENTEILEN

27. #WISSENTEILEN
In der Praxis
sieht es leider etwas anders aus.

28. #WISSENTEILEN

29. #WISSENTEILEN

30. #WISSENTEILEN#WISSENTEILEN
Hilfe, wir brauchen dringend
Architetkur
& Pattern

31. #WISSENTEILEN

32. #WISSENTEILEN
„Wie kommunizieren
Services untereinander?“
„Wer oder was ist
für die UI zuständig?“
„Wie gehen wir mit Cross-Cutting
Themen wie Logging, Tracing,
Profiling oder Security um?“
„Database per Service Pattern,
wie soll das bitte gehen?“
„Und welche Bedeutung spielt
die Versionierung der Services
und ihrer Schnittstellen?“

33. #WISSENTEILEN
Communication Pattern

34. #WISSENTEILEN
Wie kommunizieren Services untereinander?

35. #WISSENTEILEN
Communication Pattern
• RESTful (z.B. via JAX-RS 2.0)
• Messaging (z.B. via JMS 2.0)

36. #WISSENTEILEN
Communication via REST
• Ressourcen basiert
• eindeutige Identifikation via URI
• State Transfer via HTTP Methoden
• Caching via ETag, Last-Modified, …
• Request/Response Modell
• synchrone Kommunikation

37. #WISSENTEILEN
RESTful Step 1: Create order
A: POST /orders/ {order}
B: CREATED 201
Location /orders/123
Step 2: Update order
A: PUT /orders/123 {order}
B: OK 200 {order}

38. #WISSENTEILEN
Communication via REST
HTTP Methoden korrekt verwendet:
POST „creates a child resource at a server
defined URL“
PUT „creates/replaces the resource as a
whole at the client defined URL“
PATCH „updates part of the resource at that
client defined URL“

39. #WISSENTEILEN
RESTful
• Verbindungsprobleme?
• Fehler?
• Call wiederholen?
• Seiteneffekte?
• Status Codes nutzen!
• Payload nutzen!

40. #WISSENTEILEN
Communication via REST
HTTP Methoden korrekt verwendet:
SAFE
„No changes to resources at all*“
IDEMPOTENT
„No changes to resources when called repeatedly**“
*GET, HEAD, OPTIONS
** GET, HEAD, OPTIONS, PUT, DELETE

41. #WISSENTEILEN

42. #WISSENTEILEN

43. #WISSENTEILEN

44. #WISSENTEILEN

45. #WISSENTEILEN

46. #WISSENTEILEN

47. #WISSENTEILEN

48. #WISSENTEILEN

49. #WISSENTEILEN
RESTful
Aber was ist mit …
• Fire & Forget?
• Broadcast?
• Async?
Passt nicht so richtig ins
(REST) Konzept, oder?

50. #WISSENTEILEN
Communication via Messaging
• Messages zur Kommunikation
• lose Kopplung durch Queues & Topics
• ein Sender, 0 bis N Receiver
• asynchrone Kommunikation
• garantierte Auslieferung möglich

51. #WISSENTEILEN
Communication via Messaging
• plattformspezifische Formate (z.B. JMS, MSMQ)
• plattformneutrale Formate (z.B. AMQP)

52. #WISSENTEILEN
Msg Step: Send message
A: Send to topic X { msg }
B: Register to topic X
Step: Receive message
T: ACK
T: New Message in X
B: Read X

53. #WISSENTEILEN
Msg
Und was bei Problemen?
• Retry durch Sender
• Reliable Msg (Ack)
• evtl. Duplikate
• evtl. Seiteneffekte

54. #WISSENTEILEN
Msg
... und Broadcast
• bei Topics sind
mehrere parallele
Empfänger möglich

55. #WISSENTEILEN
Msg
... und Transaktionen
• via Transactional
Request*
*ACHTUNG: gilt nur bis zum Message Broker

56. #WISSENTEILEN
Msg
... und synchron
• 2x Async == Sync ;-)
• Correlation ID
• Latenz beachten

57. #WISSENTEILEN
Msg
... und synchron
• 2x Async == Sync ;-)
• Correlation ID
• Latenz beachten

58. #WISSENTEILEN
Msg
... und synchron
• 2x Async == Sync ;-)
• Correlation ID
• Latenz beachten

59. #WISSENTEILEN
Msg
... und synchron
• 2x Async == Sync ;-)
• Correlation ID
• Latenz beachten

60. #WISSENTEILEN
Msg
... und synchron
• 2x Async == Sync ;-)
• Correlation ID
• Latenz beachten

61. #WISSENTEILEN
Msg
... und synchron
• 2x Async == Sync ;-)
• Correlation ID
• Latenz beachten

62. #WISSENTEILEN
<coding-time />

63. #WISSENTEILEN

64. #WISSENTEILEN

65. #WISSENTEILEN

66. #WISSENTEILEN

67. #WISSENTEILEN#WISSENTEILEN

68. #WISSENTEILEN

69. #WISSENTEILEN
Database per Service Pattern

70. #WISSENTEILEN
Database per Service Pattern, wie soll das gehen?

71. #WISSENTEILEN
Data Integration via ...
• gemeinsame Datenquelle
• getrennte Datenquellen
• Datenreplikation

72. #WISSENTEILEN
Data Integration via ...
gemeinsame Datenquelle
Unabhängig entwickeln,
pflegen, deployen, skalieren?

73. #WISSENTEILEN
Data Integration via ...
• gemeinsame Datenquelle
• getrennte Datenquelle
• Datenreplikation

74. #WISSENTEILEN
Data Integration via ...
getrennte Datenquellen

75. #WISSENTEILEN
Data Integration via ...
getrennte Datenquellen
(lesend via Owner, schreibend via Owner)

76. #WISSENTEILEN
Data Integration via ...
Replikation von Daten

77. #WISSENTEILEN
Data Integration via ...
Replikation von Daten
(lesend via Replikation, schreibend via Owner)

78. #WISSENTEILEN
Data Integration via ...
Domain A
Domain A‘
Domain B

79. #WISSENTEILEN
Data Integration via ...
Domain A
Domain A‘
Domain B
POST
new „A“

80. #WISSENTEILEN
Data Integration via ...
Domain A
Domain A‘
Domain B

81. #WISSENTEILEN
Data Integration via ...
Domain A
Domain A‘
Domain B

82. #WISSENTEILEN
Data Integration via ...
Domain A
Domain A‘
Domain B

83. #WISSENTEILEN
Data Integration via ...
Domain A
Domain A‘
Domain B

84. #WISSENTEILEN
<coding-time />

85. #WISSENTEILEN

86. #WISSENTEILEN

87. #WISSENTEILEN

88. #WISSENTEILEN
Distributed Transactions

89. #WISSENTEILEN
Wo liegt das
Problem?

90. #WISSENTEILEN
Database per Service Pattern

91. #WISSENTEILEN
Use-Case

92. #WISSENTEILEN
Use-Case

93. #WISSENTEILEN
Use-Case

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

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

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

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

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

99. #WISSENTEILEN
The Real World is
not transactional!

100. #WISSENTEILEN
The Online World is
not transactional!

101. #WISSENTEILEN

102. #WISSENTEILEN
Der “Plan B“
Produkt im
Warenkorb
8

103. #WISSENTEILEN
Plan B: Lazy Evaluation
a.k.a. die „es wird schon gutgehen“ Strategie
• TX fachlich aufsplitten, sequentiell
durchführen und schauen, ob es klappt
• im Problemfall alternative Logik ausführen

104. #WISSENTEILEN
Plan B: Lazy Evaluation
Produkt im
Warenkorb
8

105. #WISSENTEILEN
Plan B: Lazy Evaluation
Produkt im
Warenkorb
8

106. #WISSENTEILEN
Plan B: Lazy Evaluation
Produkt im
Warenkorb
decrement
8

107. #WISSENTEILEN
Plan B: Lazy Evaluation
Produkt im
Warenkorb
decrement
8 – 1 = 7

108. #WISSENTEILEN
Plan B: Lazy Evaluation eXtended
Produkt im
Warenkorb
letzter bekannter
Bestand = 10 decrement
8 – 1 = 7
if stock > 0
else …

109. #WISSENTEILEN
Plan B: Lazy Evaluation eXtended+
Produkt im
Warenkorb
letzter bekannter
Bestand = 10 1. stock?
8 – 1 = 7
2. decrement!

110. #WISSENTEILEN#WISSENTEILEN
Plan B? Schön & gut, aber ich
brauche meine Transaktionen!
Was aber, wenn …?

111. #WISSENTEILEN
Plan B - Strategy #3: Beeing Optimistic
Produkt im
Warenkorb,
letzter bekannter
Bestand = 1
0

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

113. #WISSENTEILEN#WISSENTEILEN
TX via
SAGA Pattern

114. #WISSENTEILEN
Microservices mit „eigenen“ Daten

115. #WISSENTEILEN
Fachliche TX über Servicegrenzen hinweg

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

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

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

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

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

121. #WISSENTEILEN
Strategie #1
überdenke die
Servicegrenzen

122. #WISSENTEILEN
Die
„Service“
Strategie

123. #WISSENTEILEN
Die
„Service“
Strategie

124. #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

125. #WISSENTEILEN
Strategie #2
XA mit 2PC

126. #WISSENTEILEN
Die
„XA“
Strategie

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

128. #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

129. #WISSENTEILEN
Strategie #3
DIY 2PC

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

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

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

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

134. #WISSENTEILEN
Verteilte Transaktionen via SAGAs

135. #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

136. #WISSENTEILEN
Die
„Saga“
Strategie

137. #WISSENTEILEN
Die
„Saga“
Strategie

138. #WISSENTEILEN
Die
„Saga“
Strategie

139. #WISSENTEILEN
Die
„Saga“
Strategie

140. #WISSENTEILEN
Die
„Saga“
Strategie

141. #WISSENTEILEN
Die
„Saga“
Strategie

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

143. #WISSENTEILEN
Die
„Saga“
Strategie

144. #WISSENTEILEN
Die
„Saga“
Strategie

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

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

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

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

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

150. #WISSENTEILEN
Steuerung von SAGAs
• Choreographie
• Orchestrierung

151. #WISSENTEILEN
Steuerung von SAGAs
• Choreographie
• Orchestrierung

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

153. #WISSENTEILEN
Saga via
Choreography

154. #WISSENTEILEN
Saga via
Choreography

155. #WISSENTEILEN
Saga via
Choreography

156. #WISSENTEILEN
Saga via
Choreography

157. #WISSENTEILEN
Saga via
Choreography

158. #WISSENTEILEN
Saga via
Choreography

159. #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?)

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

161. #WISSENTEILEN
Steuerung von SAGAs
• Choreographie
• Orchestrierung

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

163. #WISSENTEILEN
Saga via Orchestration

164. #WISSENTEILEN
Saga via Orchestration

165. #WISSENTEILEN
Saga via Orchestration

166. #WISSENTEILEN
Saga via Orchestration

167. #WISSENTEILEN
Saga via Orchestration

168. #WISSENTEILEN
Saga via Orchestration

169. #WISSENTEILEN
Saga via Orchestration

170. #WISSENTEILEN
Saga via Orchestration

171. #WISSENTEILEN
Saga via Orchestration

172. #WISSENTEILEN
Saga via Orchestration

173. #WISSENTEILEN
Saga via Orchestration

174. #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)

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

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

177. #WISSENTEILEN
Frage:
Und das kann
funktionieren?

178. #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

179. #WISSENTEILEN
Konsistenz von Daten und Nachrichten

180. #WISSENTEILEN
Konsistenz von Daten und Nachrichten

181. #WISSENTEILEN
Konsistenz von Daten und Nachrichten

182. #WISSENTEILEN
Konsistenz von Daten und Nachrichten

183. #WISSENTEILEN
Konsistenz von Daten und Nachrichten

184. #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!

185. #WISSENTEILEN
UI Integration Pattern

186. #WISSENTEILEN
Wer oder was ist eigentlich für die UI zuständig?

187. #WISSENTEILEN
UI Integration
Meins, deins, unser?
• Wer liefert die UI?
• Wo baue ich die UI zusammen?
• Wie baue ich die UI zusammen?

188. #WISSENTEILEN
Client Side via Browser
• Hyperlinks (je eine Seite pro Service)
• Client Side Composition (e.g. Angular, Node)
• iFrame („fake“ Document Component Model)
• AJAX (CORS Problem, „blank“ Page)
• JavaScript Voodoo (via „myLib“)
• HTML Imports (Teil der WebComponts Spec)

189. #WISSENTEILEN
Client Side

190. #WISSENTEILEN
Client Side

191. #WISSENTEILEN
Server Side
• Server Side Include (SSI)
• Edge Side Include (ESI)
• UI Gateway

192. #WISSENTEILEN
Server Side (SSI)
• Page Composition auf Web Server Level
• Server Side Scripting Language
• einfach Syntax inkl. Kontroll-Direktiven (if, …)
• erlaubt u.a. <!--#include file|virtual=„…“ -->
• Apache httpd, LiteSpeed, nginx, lighttpd, IIS

193. #WISSENTEILEN
Server Side (ESI)
• Page Composition auf Edge Server Level
• XML basierte Syntax
• erlaubt u.a. <esi:include src=„…“ onerror=„…“ />
• CDN (Akamai)
• Proxy Caching Server (Varnish, Squid, Mongrel)

194. #WISSENTEILEN
UI Gateway
• Page Composition auf App (Server) Level
• Single Point of Entry ruft Service auf, baut aus
Ergebnissen UI zusammen und liefert sie aus
Achtung: Web UI / API Monolith!
Achtung : Kein Platz für Logik(!?)

195. #WISSENTEILEN
Gateway
„Backends
for
Frontends“
Version 1

196. #WISSENTEILEN
Gateway
„Backends
for
Frontends“
Version 2

197. #WISSENTEILEN
API Gateway Pattern

198. #WISSENTEILEN
Warum ein API Gateway?
• Clients mit unterschiedlichsten Anforderungen
kommunizieren mit dem Backend.
• Client ruft mehrere Services auf und aggregiert
intern das Ergebnis (Chatty Communication).
• Direkte Kommunikation führt zu starker
Abhängigkeit zwischen Clients und Services.

199. #WISSENTEILEN

200. #WISSENTEILEN

201. #WISSENTEILEN

202. #WISSENTEILEN
Was genau ist ein API Gateway?
• „Haupteingang“ für Anwendungen, um auf
Daten, Geschäftslogik oder Funktionen der
Backend-Services zuzugreifen.
• Zusätzlicher Layer zur Entkoppelung von
Client(s) und Backend-Services.

203. #WISSENTEILEN

204. #WISSENTEILEN

205. #WISSENTEILEN
Aufgaben des API Gateway
• „Entkopplung (Client / Services)
• Transformation (Payload, Header, …)
• Routing (Registry, Discovery)
• Orchestration (Aggregation, Fallback)
• …

206. #WISSENTEILEN
Aufgaben des API Gateway
• Security (DDoS, Authorization, Tokens, …)
• Caching (Response, CDN, …)
• Resilience (Timeout, Bandwidth, Throtteling, …)
• Staging & Versioning (dev, test, prod, mocks, …)
• Analytics (Performance, Traces, …)
• …

207. #WISSENTEILEN
Aufgaben des API Gateway
• SLAs (Bandwith, Response Time, …)
• Contracts (API-Keys, …)
• Mocking

208. #WISSENTEILEN
DIY vs. Out-of-the-Box
• Was genau möchte man erreichen?
• DIY macht nur selten Sinn!
• Netflix Zuul
• AWS Gateway
• Kong, Treafik, …
• viele, viele mehr …

209. #WISSENTEILEN
(Quelle: http://techblog.netflix.com/2013/01/optimizing-netflix-api.html)

210. #WISSENTEILEN
(Quelle: http://techblog.netflix.com/2013/01/optimizing-netflix-api.html)

211. #WISSENTEILEN
<coding-time />

212. #WISSENTEILEN

213. #WISSENTEILEN

214. #WISSENTEILEN

215. #WISSENTEILEN

216. #WISSENTEILEN#WISSENTEILEN

217. #WISSENTEILEN
Versioning

218. #WISSENTEILEN
Versionierung
Herausforderung:
Evolution der
Schnittstellen

219. #WISSENTEILEN
Best Practices: strategisch
• solange wie möglich hinauszögern
• starre Kopplung vermeiden
• Consumer-Driven Contracts
• Semantic Versioning (Major.Minor.Patch)
• Koexistenz mehrerer Endpoints
• Konkurrierende Service Versionen

220. #WISSENTEILEN

221. #WISSENTEILEN
Ver 0.6.0
{
"id": 1,
"fullName": "Max Mustermann",
"emailAdress": "max.mustermann@openknowledge.de"
}
Change request: add gender

222. #WISSENTEILEN
Ver 0.7.0
{
"id": 1,
"fullName": "Max Mustermann",
"gender": true,
"emailAdress": "max.mustermann@openknowledge.de"
}

223. #WISSENTEILEN
Ver 0.7.0
{
"id": 1,
"fullName": "Max Mustermann",
"gender": true,
"emailAdress": "max.mustermann@openknowledge.de"
}
Change request: split „fullName“

224. #WISSENTEILEN
Ver 0.8.0
{
"id": 1,
"firstName" : "Max",
"lastName" : "Mustermann",
"gender": true,
"emailAdress": "max.mustermann@openknowledge.de"
}

225. #WISSENTEILEN
Ver 0.8.0
{
"id": 1,
"firstName" : "Max",
"lastName" : "Mustermann",
"gender": true,
"emailAdress": "max.mustermann@openknowledge.de"
}
Missing fullName!

226. #WISSENTEILEN
Ver 0.8.0
{
"id": 1,
"fullName": "Max Mustermann",
"firstName" : "Max",
"lastName" : "Mustermann",
"gender": true,
"emailAdress": "max.mustermann@openknowledge.de"
}
Change request: structure for „name/fullName“

227. #WISSENTEILEN
Ver 0.9.0
{
"id": 1,
"fullName" {
"firstName" : "Max",
"lastName" : "Mustermann",
}
"gender": true,
"emailAdress": "max.mustermann@openknowledge.de"
}

228. #WISSENTEILEN
Ver 0.9.0
{
"id": 1,
"fullName" {
"firstName" : "Max",
"lastName" : "Mustermann",
}
"gender": true,
"emailAdress": "max.mustermann@openknowledge.de"
}
Semantic of fullName!

229. #WISSENTEILEN
Ver 0.9.0
{
"id": 1,
"fullName": "Max Mustermann",
"name" {
"firstName" : "Max",
"lastName" : "Mustermann",
}
"gender": true,
"emailAdress": "max.mustermann@openknowledge.de"
}

230. #WISSENTEILEN
Ver 1.0.0
{
"id": 1,
"fullName": "Max Mustermann",
“name" {
"firstName" : "Max",
"lastName" : "Mustermann",
}
"gender": "male",
"emailAddress": "max.mustermann@openknowledge.de"
}

231. #WISSENTEILEN
Ver 1.0.0
{
"id": 1,
"fullName": "Max Mustermann",
“name" {
"firstName" : "Max",
"lastName" : "Mustermann",
}
"gender": "male",
"emailAddress": "max.mustermann@openknowledge.de"
}

232. #WISSENTEILEN
„Be conservative in what you do,
be liberal in what you accept.“
Postel’s Law (a.k.a. robustness principle)

233. #WISSENTEILEN
Best Practices: technisch
• gar nicht (via „ignore“)
• gar nicht (via zusätzlicher Ressourcen)
• gar nicht (via erweiterbarer Datenformate)
• Versionsnummer in URL
• Versionsnummer in Header (via Custom-Header)
• Content Negotiation (via Accept-Header)

234. #WISSENTEILEN
via
Endpoints
Endpoint V1
Versioning

235. #WISSENTEILEN
via
Endpoints
Endpoint V1
Endpoint V2
Versioning

236. #WISSENTEILEN
via
Endpoints
Endpoint V2
Versioning

237. #WISSENTEILEN
via
Services
Service V1
Versioning
Endpoint

238. #WISSENTEILEN
via
Services
Service V1
Service V2
Versioning
Old Endpoint New Endpoint

239. #WISSENTEILEN
via
Services
Service V2
Versioning
Endpoint

240. #WISSENTEILEN
„Wo bitte ist das Problem?
Dann habe ich eben X Versionen!“
(naiver Entwickler)

241. #WISSENTEILEN
Evolution: Monolith

242. #WISSENTEILEN
Evolution: Microservices

243. #WISSENTEILEN
Evolution: Microservices
Wie ist die Anzahl der möglicher Konstellationen?

244. #WISSENTEILEN
Evolution: Microservices
fixe Reihenfolge: N-1 Kombinationen (N=4; 3)

245. #WISSENTEILEN
Evolution: Microservices
Beliebige Reihenfolge: 2N-2 Kombinationen (N=4; 14)

246. #WISSENTEILEN
„REST APIs don‘t need a
versioning strategy – they need
a change strategy!“
Ben Morris (Ben Morris Blog)

247. #WISSENTEILEN
Pitfalls

248. #WISSENTEILEN
#1
Cohesion
chaos

249. #WISSENTEILEN
#2
Not taken
automation
seriously

250. #WISSENTEILEN
#3
Layered
Service
Architecture

251. #WISSENTEILEN
#4
Relying
on consumer
sign-in

252. #WISSENTEILEN
#5
Manual
configuration
managment

253. #WISSENTEILEN
#6
Version
avoidance

254. #WISSENTEILEN
#7
A gateway
for every Service

255. #WISSENTEILEN
Are u ready for Microservices?

256. #WISSENTEILEN
„Ein Microservice
kommt selten allein!“
Lars Röwekamp

257. #WISSENTEILEN
Service
Design

258. #WISSENTEILEN
Architectural
Pattern

259. #WISSENTEILEN
Communication
Pattern

260. #WISSENTEILEN
API
Gateway

261. #WISSENTEILEN
UI
Integration

262. #WISSENTEILEN
API
Versioning

263. #WISSENTEILEN
? ? ?

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

265. #WISSENTEILEN
Bildnachweise 1/2
#25: © marekukiasz– shutterstock.com
#42: © print10 – istockphoto.com
#90: © vasakna – fotolia.com
#113: © vadymvdrobot – fotolia.com t
#223: © Rawpixel.com – shutterstock.com
#260: © RichVintage - istockphoto.com

266. #WISSENTEILEN
Bildnachweise 2/2
All other pictures inside this presentation orginate from
pixabay.com or were created by my own.