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!
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
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.
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!
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
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
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
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
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!
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
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
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)
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
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?“
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
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?
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.
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
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
• …
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
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
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