Microservices-basierte Architekturen auf der grünen Wiese zu starten mag ja noch vorstellbar sein. Was aber, wenn es – wie leider so häufig in der Praxis – einen bestehenden, historisch gewachsenen Monolithen gibt, der schon einmal bessere Tage gesehen hat? Wie kann ein möglicher Migrationspfad aussehen und mit welchen Stolperfallen muss dabei gerechnet werden? Im Rahmen des Workshops nehmen wir uns anhand eines konkreten Beispiels einen solchen Monolithen vor, überlegen, welche Services sich sinnvoll herauslösen lassen und welche Patterns dazu verwendet werden sollten. Natürlich ergeben sich durch die neue Architektur auch neue Herausforderungen, denen wir uns stellen müssen. Aber das kann uns natürlich nicht stoppen!

1. #WISSENTEILEN
The
MICROSERVICES
SURVIVAL GUIDE
#WISSENTEILEN
THE PRACTICAL SKILLS YOU‘LL
NEED TO MIGRATE A MONOLITH
by Lars Röwekamp
a.k.a @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
Lars Röwekamp (a.k.a. @mobileLarson)
LR

4. #WISSENTEILEN
Herzlich
willkommen!

5. #WISSENTEILEN

6. #WISSENTEILEN
Monolith?
Eigentlich ganz cool!

7. #WISSENTEILEN
bekannte Architektur
IDE freundlich
DB als „Source of Truth“

8. #WISSENTEILEN
einfach zu verteilen
einfach zu testen
einfach zu deployen

9. #WISSENTEILEN
Monolith
Eigentlich ganz cool, aber!

10. #WISSENTEILEN
#SOC:
#API:
#DRY:
#LOD:
#DDD:
#YAGNI:
Separation of Concerns
High Cohesion & Low Coupling
Don‘t repeat yourself
Law of Demeter
Domain Driven Design
You aren‘t going to need it

11. #WISSENTEILEN

12. #WISSENTEILEN

13. #WISSENTEILEN

14. #WISSENTEILEN

15. #WISSENTEILEN
Probleme
wohin man schaut

16. #WISSENTEILEN
Umsetzungsstau

17. #WISSENTEILEN
Release Qualität

18. #WISSENTEILEN
Robustheit

19. #WISSENTEILEN
Kosten

20. #WISSENTEILEN
Skalierbarkeit

21. #WISSENTEILEN
Zukunftsfähigkeit

22. #WISSENTEILEN
Universallösung
Microservices

23. #WISSENTEILEN
„Glaub mir,
Microservices
sind das
‚next big Thing‘!“

24. #WISSENTEILEN
Microservices
Charateristics(Things that make a Microservice a Microservice)

25. #WISSENTEILEN
„Functional Decompensation“
„Single Responsibility Pattern“
„Explicitly Published Interfaces“
„Independently upgrade, ...“
„Lightweight Communication“

26. #WISSENTEILEN
und ...
Business Driven

27. #WISSENTEILEN
(c) Martin Fowler: https://www.martinfowler.com/bliki/MicroservicePremium.html

28. #WISSENTEILEN
Microservices-basierte
Architektur
erfolgreiche
Software
Entwicklung
Continuous Delivery / Deployment
ermöglichtermöglicht
kleine, agile, unabhängige,
cross-functional Teams
ermöglicht
Services
sind unabhängig
testbar & deploybar
Teams
besitzen Services
Prozesse
ArchitekturOrganisation

29. #WISSENTEILEN
Baustelle #1
Architektur

30. #WISSENTEILEN
Baustelle #1 Architektur
„Was ist die richtige Größe für einen
Service und wie sieht am Ende
meine Service-Landkarte aus?“

31. #WISSENTEILEN
Baustelle #2
Organisation

32. #WISSENTEILEN
Baustelle #2 Organisation
„Wie stelle ich meine Teams auf agiles
Vorgehen um und was bedeuten das
für die restliche Organisation?“

33. #WISSENTEILEN
Baustelle #3
Prozesse

34. #WISSENTEILEN
Baustelle #3 Prozesse
„Was muss ich tun, um CI/CD zu
ermöglichen und welchen Grad der
Automatisierung benötige ich dazu?“

35. #WISSENTEILEN
Migration?
Wir brauchen eine Strategie

36. #WISSENTEILEN
Vom Monolithen …

37. #WISSENTEILEN
… zu Microservices

38. #WISSENTEILEN
?
Migrationsstrategie

39. #WISSENTEILEN
Big Bang

40. #WISSENTEILEN
Der „Big Bang“

41. #WISSENTEILEN
Der „Big Bang“
Microservice-basierte Anwendung „from the
scratch“ neu aufbauen
pro:
• keine Altlasten parallel zu pflegen
contra:
• sehr viele NEUE Baustellen gleichzeitig

42. #WISSENTEILEN
Der „Big Bang“
„The only thing a Big Bang rewrite
garantuees is a Big Bang!“
Martin Fowler

43. #WISSENTEILEN
Strangler
Application

44. #WISSENTEILEN
Die „Strangler Application“

45. #WISSENTEILEN
Die „Strangler Application“
Microservice-basierte Anwendung „parallel“ zu
bestehendem Monolithen aufbauen
pro:
• geringeres Risiko dank inkrementeller Lernkurve
contra:
• parallele Pflege von zwei Systemen

46. #WISSENTEILEN
Strategie #1
Stop Digging

47. #WISSENTEILEN
Die „Stop Digging“ Strategie
„Whenever you find yourself in a hole,
you should stop digging!“
The Law of Hole

48. #WISSENTEILEN
Die „Stop Digging“ Strategie
Neue Funktionalität nicht im Monolithen
implementieren sondern in einem eigenen
Microservice
• vorgeschalteter Router als Logik-Dispatcher
• Glue-Code zur Data-Integration

49. #WISSENTEILEN
Die „Stop Digging“ Strategie
Glue-Code als Anti-Corruption Layer, zur
sauberen Trennung der Domain Modelle von
Microservice und Monolith. Datenintegration?
• Aufruf einer Remote API des Monolithen
• direkter Zugriff auf DB des Monolithen
• Halten einer eigenen Daten-Kopie inkl. Sync.

50. #WISSENTEILEN
Die
„Stop Digging“
Strategie

51. #WISSENTEILEN
Die
„Stop Digging“
Strategie

52. #WISSENTEILEN
Die „Stop Digging“ Strategie
pro:
• Monolith wird nicht noch unwartbarer
• Service ist „unabhängig“ vom Monolithen
• Microservices-Erfahrung kann langsam wachsen
contra:
• Probleme des Monolithen bleiben bestehen!

53. #WISSENTEILEN
Strategie #2
Split Front/Back

54. #WISSENTEILEN
Die „Split Front/Back“ Strategie
Trennen des Frontends von Business-Logik und
Persistenz.
• aus eins mach zwei
• „natürliche“ Trennung zwischen Presentation-
Logik und Business-Logik nutzen
• Zugriff auf Backend via coarse-grained API

55. #WISSENTEILEN
Die „Split Front/Back“ Strategie

56. #WISSENTEILEN
Die „Split Front/Back“ Strategie

57. #WISSENTEILEN
Die „Split Front/Back“ Strategie
pro:
• Möglichkeit, beide „Welten“ getrennt zu
entwickeln, deployen und skalieren
• Remote API, z.B. REST, für zukünftige
Microservices als positives Abfallprodukt
contra:
• keine finale Lösung sondern eher ein Übergang

58. #WISSENTEILEN
Strategie #3
Extract Services

59. #WISSENTEILEN
Die „Extract Services“ Strategie
Bestehende Module des Monolithen extrahieren
und in „standalone“ Microservices überführen
• Monolith schrumpft mit jedem Service
• am Ende bleibt kein/ein extrem kleiner Monolith
• Feature Toggles als „Weiche“ nutzen

60. #WISSENTEILEN
Die „Extract Services“ Strategie
Vorgehen beim Herauslösen von Modulen in
eigene Microservices:
• Coarse-grained Interface definieren
• Module standalone lauffähig machen
• ggf. Features in Monolithen “deaktivieren“*
*Achtung: kann teure Rückbaumaßnahmen bedeuten

61. #WISSENTEILEN
Die „Extract Services“ Strategie

62. #WISSENTEILEN
Die „Extract Services“ Strategie

63. #WISSENTEILEN
Die „Extract Services“ Strategie

64. #WISSENTEILEN
Die „Extract Services“ Strategie
pro:
• Step-by-Step Migration
• Monolith verschwindet im Laufe der Zeit
contra:
• Auslagern von Services bedeutet Aufwand
in beiden Welten

65. #WISSENTEILEN
Los geht‘s.
Aber wie?

66. #WISSENTEILEN
FAQs
• Wie komme ich zu den richtigen Services?
• Was ist die richtige Anzahl an Services?
• Was ist die richtige Migrationsreihenfolge?
• Wie migriere ich die DB richtig?
• Welcher Herausforderungen erwarten mich?
• Und der Monolith? Den gibt es doch auch noch!

67. #WISSENTEILEN
Service Design

68. #WISSENTEILEN

69. #WISSENTEILEN

70. #WISSENTEILEN

71. #WISSENTEILEN

72. #WISSENTEILEN
Der goldene Schnitt
„Wie schneide ich
Microservices richtig?“
(DI 9:00 – 12:30 Uhr)Speaker
Arne Limburg

73. #WISSENTEILEN
Guter Service, schlechter Service
Single Responsibility
• Service deckt genau eine Fachlichkeit ab
• Bounded Context

74. #WISSENTEILEN
Guter Service, schlechter Service
Share Nothing
• „private“ Implementierung
• „private“ Datenbank
• Kommunikation ausschließlich via APIs

75. #WISSENTEILEN
Guter Service, schlechter Service
Idependence
• planen
• entwickeln
• bauen
• testen
• “live“ stellen

76. #WISSENTEILEN
Guter Service, schlechter Service
Polyglot
• “best X for the job“ mit dem Ziel der Skalierung
• Technology
• Data Management
• Business Logic
• Skalierung

77. #WISSENTEILEN
Guter Service, schlechter Service
• hohe Cohesion innerhalb des Service
• lose Koppelung zwischen Services
• Änderungshäufigkeit ähnlich
• businesskritische Prozesse nah beisammen
• Eventual Consistency akzeptabel
• Designe for Failure

78. #WISSENTEILEN
Wie groß ist Klein

79. #WISSENTEILEN
Wie groß ist klein
„Don‘t make services as
small as possible.“
(Stefan Tilkov)

80. #WISSENTEILEN
Wie groß ist klein
„Small enough and not smaller“
(Sam Newmann)

81. #WISSENTEILEN
Wie groß ist klein
„Created by no more than
a handful of people“
(Michael Feathers)

82. #WISSENTEILEN
Wie groß ist klein
„Microservices is a label,
not a description.“
(Martin Fowler)

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

84. #WISSENTEILEN
Wie groß ist klein
Size of microservice
„guter“
Microservice
Modularisierung
Teamgröße
Austauschbarkeit
Infrastruktur
Verteilte
Kommunikation
Transaktionen &
Konsistenz

85. #WISSENTEILEN
Wie groß ist klein
Team Size

86. #WISSENTEILEN
Wie groß ist klein
Team Size

87. #WISSENTEILEN
Size of microservice
Number of microservices

88. #WISSENTEILEN
Migration Roadmap

89. #WISSENTEILEN

90. #WISSENTEILEN
Motivation für Microservices*
• Agilität?
• Robustheit?
• Kosten?
• Innovationen?
*es kann nur eine höchste Priorität geben

91. #WISSENTEILEN
Einflussfaktoren für die Migration
• Lernkurve?
• Risikominimierung?
• Sichtbarkeit / Business Mehrwert?
• Aufwand?
• Bindung von Kapazitäten?
• Abhängigkeiten?

92. #WISSENTEILEN
Phase 1: Warm up
Starten mit einem möglichst einfachen Service*, der
wenig Kopplung zur restlichen Anwendung hat.
• Fokus auf Operational Readiness (CI/CD)
• Fokus auf Microservices Infrastruktur*
• Fokus auf verteilter Architektur*
• Fokus auf Organizational Change *(e.g. Service Mesh)

93. #WISSENTEILEN
Phase 1: Warm up
*(Martin Fowler: Microservices Prerequisites)
• Rapid Provisioning
• Basic Monitoring
• Rapid App Deployment

94. #WISSENTEILEN
Phase 1: Warm up
„alter“ Monolith
mit Funktionalität
Authentication
„neuer“ Monolith
neuer
Authentication
Service
Migration
neue Delivery Infrastructure

95. #WISSENTEILEN
Phase 2: Minimize Dependencies
Wähle Services ohne/mit wenig Rückkoppelungen
zum Monolithen.
• Rückkoppelungen forcieren Abhängigkeiten in
der Entwicklung und der Release-Planung
• minimiere bestehende Abhängigkeiten durch
Anti-Corruption Layer

96. #WISSENTEILEN
Phase 2: Minimize Dependencies
„alter“ Monolith
mit Abhängigkeiten
„neuer“ Monolith
ohne Abhängigkeiten
ausgelagerter Service
mit unidirektionalen
Abhängigkeiten
MigrationMigration

97. #WISSENTEILEN
Phase 2: Minimize Dependencies
„alter“ Monolith
mit Abhängigkeiten
„neuer“ Monolith
ohne Abhängigkeiten
ausgelagerter Service
mit bidirektionalen
Abhängigkeiten und ACL
Migration
ACL
Migration

98. #WISSENTEILEN
Phase 3: Sticky first
Wähle stark verwobene Fachlichkeit und löse diese
sauber auf („DDD ist dein Freund“)
• oft hindern einen unsaubere, historisch
gewachsene Domänenmodelle daran,
weitere sinnvolle Services herauszulösen

99. #WISSENTEILEN
Phase 3: Sticky first
„alter“ Monolith
mit sticky Session
„neuer“ Monolith
ohne sticky Session
ausgelagerte
Services
Migration
Customer
Session
Customer
Profile
Customer
Payment
Method
Customer
Wishlist

100. #WISSENTEILEN
Phase 4: Decouple vertically
Löse Services komplett inklusive „user facing“
Komponenten und DB heraus.
• Bereitstellung von entwicklerfreundlichen APIs
für moderne UIs via Facade Service bringt
lediglich Quick-Wins.
• erst ein Aufsplitten inkl. Trennung der Daten
bringt echten Mehrwert

101. #WISSENTEILEN
Phase 4: Decouple vertically
„alter“ Monolith Services
Migration
„neuer“ Monolith
user
facing
backend
logic
data /
comms
neue
UI / UX
neue API

102. #WISSENTEILEN
Phase 5: Decouple important stuff
Löse Services mit höchstem Mehrwert heraus.
• Es gilt Kosten gegen Nutzen abzuwägen.
• Was ist wichtig?
• Was ändert sich häufig?
• Was muss unabhängig skalieren können?

103. #WISSENTEILEN
Phase 5: Decouple important stuff
„alter“ Monolith
mit wichtigster
Komponente
„neuer“ Monolith
ohne wichtigste
Komponente
ausgelagerte
wichtigste
Komponente
Migration

104. #WISSENTEILEN
Phase 6: Decouple capabilities*
Wäge sinnvoll zwischen Reuse und Rewrite ab.
• nicht blind altem Code übernehmen
• alter Code beinhaltet oft Boilerplate und
berücksichtigt keine Domänengrenzen
• retire and rewrite als Alternative
• IKEA Effekt lässt uns wachsen *(… and not code!)

105. #WISSENTEILEN
Phase 6: Decouple capabilities
„alter“ Monolith „neuer“ Monolith
Customer
Profile
Service
Migration
Pricing
Service
reuse
rewrite
extract?
retire?
neue Services
via reuse oder rewrite

106. #WISSENTEILEN
Phase 6: Go Marco first, then Micro
Starte mit Bounded Contexts (DDD) als
Servicegrenzen und verfeinere später bei Bedarf.
• kleine Service bringen oft neue Abhängigkeiten
• kleine Services spiegeln meist DB Sicht wieder*
Distributed Monolith vs. Microservices
*(Anemic Services)

107. #WISSENTEILEN
Phase 6: Go Marco first, than Micro
Migration
Step 1
Migration
Step 2
„alter“
Monolith
„neuer“
Monolith
Buy
Service
Checkout
Service
Shopping Cart
Service
Hyperlink

108. #WISSENTEILEN
Phase 7: Atomic Evolutionary Steps
Plane die Migration in „atomaren“ Schritten.
Schaffe dabei stabile Zwischenstände.
• Migration kann aus verschiedensten Gründen
gestoppt werden. Rückbau? Chaos?
• Short Term Plans vs. Long Term Plans

109. #WISSENTEILEN
Phase 7: Atomic Evolutionary Steps
(Quelle: Thoughtworks)

110. #WISSENTEILEN
Migration RoadmapW
arm
Up
Minimizedependencies
Stickyfirst
Decouplevertically
Decoupleimportantstuff
Decouplecapabilities
GoMacro,thanMicro
Atomicsteps
Step 1 Step 2 Step 3 Step N

111. #WISSENTEILEN
Microservices Challenges

112. #WISSENTEILEN
Es könnte alles
sooo einfach sein!

113. #WISSENTEILEN

114. #WISSENTEILEN

115. #WISSENTEILEN
... isses aber
nich!

116. #WISSENTEILEN
Microservices
Q&A(Things you better care about!)

117. #WISSENTEILEN
„Welche Services laufen?“
„Sind die Routing-Infos aktuell?“
„Gibt es ‚Chains of Failure‘?“
„Message-Typen im System?“
„Sind die Services sicher?“
„Sind die Daten konsistent?“

118. #WISSENTEILEN
Service Discovery

119. #WISSENTEILEN
Wo ist mein Service ...
• Anzahl der Service-Instanzen variiert
• Adressen werden dynamisch zugewiesen
• Client muss den „richtigen“ Service finden
• Services registrieren sich bei Registry
• Client fragt bei Registry nach

120. #WISSENTEILEN

121. #WISSENTEILEN

122. #WISSENTEILEN
Service Registry/Discovery PLUS
• Load Balancing
• Failure Detection & Health Checks
• Cluster Replication
• Key/Value Storage

123. #WISSENTEILEN
Wo ist mein Service ...
Client-Side Service Discovery
• Netflix Eureka / Consul + Ribbon Client
• Apache Zookeeper + Zookeeper Client
Server-Side Service Discovery
• AWS Elastic Load Balancer
• Consul / NGNIX Plus + Consul Templating

124. #WISSENTEILEN
Wo ist mein Service ...
Client-Side Service Discovery
• Netflix Eureka / Consul + Ribbon Client
• Apache Zookeeper + Zookeeper Client
Server-Side Service Discovery
• AWS Elastic Load Balancer
• Consul / NGNIX Plus + Consul Templating
Und was ist mit
Kubernetes?

125. #WISSENTEILEN
<coding-time />

126. #WISSENTEILEN

127. #WISSENTEILEN

128. #WISSENTEILEN#WISSENTEILEN

129. #WISSENTEILEN

130. #WISSENTEILEN

131. #WISSENTEILEN
Fault Tolerance

132. #WISSENTEILEN

133. #WISSENTEILEN
Not available, please call later ...
Ziel ist es, ein „elastisches“, sich selbst
regenerierendes System zu schaffen, um so
eine bestmögliche Verfügbarkeit zu
gewährleisten.

134. #WISSENTEILEN
Not available, please call later ...
Das System sollte jederzeit fachlich
sauber funktionieren.

135. #WISSENTEILEN
Im Fokus stehen ...
Verfügbarkeit
Fehlertoleranz

136. #WISSENTEILEN
Pattern: Traffic Avoidance
• Traffic minimieren via Caching
• Traffic optimieren via Batching

137. #WISSENTEILEN
Pattern: Design for Failure
• Fehler als Normalfall nicht als Ausnahme
• Automatische Fehlerbehandlung
• Netflix stellt regelmäßig Systeme ab

138. #WISSENTEILEN
Pattern: Fail sooner than later
• Probleme frühzeitig erkennen
• Fehler gar nicht erst entstehen lassen
• Monitoring von Metrics & Response Times
• Monitoring von Buisness KPIs

139. #WISSENTEILEN
Pattern: Meaningful Responses
• liefern von Fallbacks / Defaults
• Services-Consumer fehlertolerant
• wie beeinflusst ein Fehler die UX?

140. #WISSENTEILEN

141. #WISSENTEILEN
Not available, please call later ...
• Load Balancing (als Basis von „SLAs“)
• Retry on Failure (Temporary Failures)
• Timeouts (Poor Mans Circuit Breaker)
• Circuit Breaker („Sicherung“ für Fail Fast )
• Bulkheads (Dedicated Threadpools)

142. #WISSENTEILEN
Circuit
Breaker

143. #WISSENTEILEN
Circuit
Breaker

144. #WISSENTEILEN
Bulkheads

145. #WISSENTEILEN
Bulkheads

146. #WISSENTEILEN
Bulkheads

147. #WISSENTEILEN
Not available, please call later ...
• DIY Pattern? No way!
• Hystrix, the one and only! Not anymore.
• MicroProfile Fault Tolerance
• Istio Service Mesh
• Traefik Gateway
• …

148. #WISSENTEILEN
<coding-time />

149. #WISSENTEILEN

150. #WISSENTEILEN

151. #WISSENTEILEN

152. #WISSENTEILEN

153. #WISSENTEILEN

154. #WISSENTEILEN

155. #WISSENTEILEN

156. #WISSENTEILEN
Distributed Security

157. #WISSENTEILEN
Sicher ist sicher! Sicher?
• Application Level (Authentication)
• User Level (Authorization)
• Network Level (Ports, OS, Protocols, ...)

158. #WISSENTEILEN
Sicher ist sicher! Sicher?
• Single Sign On? Single Sign Off?
• Security Context Propagation / Delegation?
• „Deep“ Auth vs. Border Access Control?

159. #WISSENTEILEN
Sicher ist sicher! Sicher?
• Authentication
a.k.a. Hotelrezeption
• Authorization
a.k.a. Zimmerschlüssel

160. #WISSENTEILEN
Sicher ist sicher! Sicher?
• 401 „Unauthorized“
meint eigentlich “Unauthenticated“
• 403 „Forbidden“
meint eigentlich „Unauthorized“

161. #WISSENTEILEN
Sicher ist sicher! Sicher?
• Server based Security
via Session auf dem Server
• Token based Security
via Austausch von Token

162. #WISSENTEILEN
Server
based
Security

163. #WISSENTEILEN
Token
based
Security

164. #WISSENTEILEN
Sicher ist sicher! Sicher?
JWT (JSON Web Token)
• neue, einfache und kompakte Specs
• Token plus public & private „Claims“
• digitale Signatur und/oder Encryption
• als Bearer Token und für SSO

165. #WISSENTEILEN

166. #WISSENTEILEN
Warum JWT?
• ... vs. SWT
• ... vs. SAML
• public/private Keys
• extrem kompakt
• JSON

167. #WISSENTEILEN
Sicher ist sicher! Sicher?
JWT & API Goals
• Authorize Request
• Verify Sender
• Avoid Man in the Middle
• Expiration
• Request Cloning

168. #WISSENTEILEN
<coding-time />

169. #WISSENTEILEN

170. #WISSENTEILEN

171. #WISSENTEILEN

172. #WISSENTEILEN

173. #WISSENTEILEN
Logging & Monitoring

174. #WISSENTEILEN
Alles im Blick
• tech. Komponenten (e.g. Request/s in DB)
• Business Metrics (Orders/min)
• semantisches Monitoring als Frühwarnsystem
• Team kann vor dem Fehler einschreiten
• Team kann System permanent verbessern

175. #WISSENTEILEN

176. #WISSENTEILEN

177. #WISSENTEILEN
Log Aggregation & Monitoring
• Elastic Stack (Elastic Search, Logstash, Kibana)
• via Log Appender (Socket Appender)
• in Echtzeit
• Logstash / Beats - collect
• Elastic Search - store & search
• Kibana - analyze & visualize

178. #WISSENTEILEN

179. #WISSENTEILEN
Log Aggregation & Monitoring
Alternativen?
• Splunk
• App Dynamics
• New Relic
• GreyLog (open source)

180. #WISSENTEILEN

181. #WISSENTEILEN

182. #WISSENTEILEN

183. #WISSENTEILEN

184. #WISSENTEILEN

185. #WISSENTEILEN
<coding-time />

186. #WISSENTEILEN

187. #WISSENTEILEN
Configuration Management

188. #WISSENTEILEN
Sorry, configuration changed!
• viele Service
• viele Service Teams
• viele Konfigurationen
• viele Konfigurationsänderungen
• Willkommen im Chaos!

189. #WISSENTEILEN

190. #WISSENTEILEN

191. #WISSENTEILEN
Sorry, configuration changed!
• Self-made
• Configuration Manager (Netflix Archaius)
• Service Discovery Server (Consul, …)
• Automation Server (Puppet, Chef, …)
• Vault „Secrets“ Server

192. #WISSENTEILEN
<coding-time />

193. #WISSENTEILEN

194. #WISSENTEILEN

195. #WISSENTEILEN
Lessons Learned

196. #WISSENTEILEN
Lessons Learned
Priorisierung, welches Modul zu welchem Zeitpunkt
als Microservice rausgelöst werden soll:
• z.B. „einfache“ Module zuerst (Erfahrung
sammeln), „Problemkinder“ danach (Mehrwerte
schaffen)
• Ranking: Change-Frequenz, Ressourcen-
Verbrauch, Skalierung, Kommunikation, ...

197. #WISSENTEILEN
Lessons Learned
Ist das schon alles?
• Zeitpunkt für DB-Migration will gut überlegt sein
• Microservice-Infrastruktur Step-by-Step mit
wachsender Anzahl an Services aufbauen
(Registry, Gateway, Resilience ...)

198. #WISSENTEILEN
Lessons Learned
• Ohne Domain Driven Design geht es nicht
• Ports & Adapter für einfachere Extraktion
• explizite Service/Endpoint Ownership
• Source-Versionierung statt toter Code
• Monitoring ist die Basis für ALLES
• Env-Var Dokumentation ist PFLICHT

199. #WISSENTEILEN
Lessons Learned
• Domäne vor Technologie
• vermeide „Shared Data“
• nutze Events zur Synchronisation von Daten
• nutze Events zur Kompensation (Business-TX)
• gebe Async den Vorzug über Sync
• Testing via Consumer-driven Contracts

200. #WISSENTEILEN
Are u ready to Take-off?

201. #WISSENTEILEN

202. #WISSENTEILEN
Martin sagt ...
• Rapid Provisionierung
• Basic Monitoring
• Rapid App Deployment
(Quelle: http://martinfowler.com/bliki/MicroservicePrerequisites.html)

203. #WISSENTEILEN
Martin sagt ...
(Quelle: http://martinfowler.com/bliki/MicroservicePrerequisites.html)

204. #WISSENTEILEN
Are u ready
for this ...
powered by

205. #WISSENTEILEN
Are u ready
for this ...
powered by

206. #WISSENTEILEN
Are u ready
for this ...

207. #WISSENTEILEN
Ich sage ...

208. #WISSENTEILEN
Ich sage ...

209. #WISSENTEILEN
Ich sage ...

210. #WISSENTEILEN
Ich sage ...

211. #WISSENTEILEN
Ich sage ...

212. #WISSENTEILEN
? ? ?

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

214. #WISSENTEILEN
Bildnachweise 1/3
#1: © fabrikaSimf – shutterstock.com
#5: © Daniel Steger for openphoto.net
#91: © marekuliasz – shutterstock.com
#131: © Freedomz – shutterstock.com
#141: © print10 – istockphoto.com
#223: © RichVintage - istockphoto.com

215. #WISSENTEILEN
Bildnachweise 2/3
#225: https://www.thoughtworks.com/insights/blog/microservices-
how-large-enterprise-grew-doing-it
#227: © embarc (mit freundlicher Genehmigung)
#231: © marekuliasz - istockphoto.com
#232: © alphaspirit - istockphoto.com
#232: © newafrica - istockphoto.com

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