Оглавление
Sam Newman. Vom Monolithen zu Microservices
Vom Monolithen zu Microservices
Inhalt
Vorwort
Was Sie lernen werden
Konventionen in diesem Buch
Danksagung
KAPITEL 1. Gerade genug Microservices
Was sind Microservices?
Unabhängige Deploybarkeit
Modellierung rund um eine Businessdomäne
Die eigenen Daten besitzen
Welche Vorteile können Microservices haben?
Welche Probleme werden entstehen?
Benutzeroberflächen
Technologie
Größe
Und Ownership
Der Monolith
Der Ein-Prozess-Monolith
Und der modulare Monolith
Der verteilte Monolith
Black-Box-Systeme von Fremdherstellern
Herausforderungen von Monolithen
Vorteile von Monolithen
Zu Kopplung und Kohäsion
Kohäsion
Kopplung
Implementierungskopplung
Zeitliche Kopplung
Deployment-Kopplung
Domänenkopplung
Gerade genug Domain-Driven Design
Aggregat
Kontextgrenzen
Aggregate und Kontextgrenzen auf Microservices abbilden
Weitere Quellen
Zusammenfassung
KAPITEL 2. Eine Migration planen
Das Ziel verstehen
Drei zentrale Fragen
Warum wollen Sie Microservices einsetzen?
Teamautonomie verbessern
Können Sie das auch anders erreichen?
Time-to-Market verringern
Können Sie das auch anders erreichen?
Kostengünstig auf Last reagieren
Können Sie das auch anders erreichen?
Robustheit verbessern
Können Sie das auch anders erreichen?
Die Anzahl der Entwickler erhöhen
Können Sie das auch anders erreichen?
Neue Technologien einsetzen
Können Sie das auch anders erreichen?
Wann können Microservices eine schlechte Idee sein?
Unklare Domäne
Start-ups
Beim Kunden installierte und verwaltete Software
Keinen guten Grund haben!
Abwägungen
Die Menschen mitnehmen
Organisationen verändern
Gefühl für die Dringlichkeit vermitteln
Führungskoalition schaffen
Vision und Strategie entwickeln
Veränderungsvision kommunizieren
Mitarbeitern umfangreiche Unterstützung ermöglichen
Kurzfristige Erfolge erzielen
Nutzen konsolidieren und weitere Veränderungen anstoßen
Neue Ansätze in der Unternehmenskultur verankern
Die Wichtigkeit der inkrementellen Migration
Nur die Produktivumgebung zählt
Veränderungskosten
Reversible und irreversible Entscheidungen
Bessere Orte zum Experimentieren
Wo fangen wir also an?
Domain-Driven Design
Wie weit müssen Sie gehen?
Event Storming
Ein Domänenmodell zum Priorisieren einsetzen
Ein kombiniertes Modell
Teams reorganisieren
Sich verändernde Strukturen
Es gibt nicht die eine Lösung für alle
Eine Änderung vornehmen
Veränderte Fähigkeiten
Woher wissen Sie, ob die Transformation funktioniert?
Regelmäßige Checkpoints
Quantitative Messgrößen
Qualitative Messwerte
Vermeiden Sie den Sunk-Cost-Effekt
Seien Sie offen für neue Ansätze
Zusammenfassung
KAPITEL 3. Den Monolithen aufteilen
Ändern wir den Monolithen, oder lassen wir es bleiben?
Ausschneiden, einfügen oder reimplementieren?
Den Monolithen refaktorieren
Ein modularer Monolith?
Inkrementelles Überarbeiten
Migrations-Patterns
Pattern: Strangler Fig Application
Wie es funktioniert
Wo wir es einsetzen
Beispiel: HTTP Reverse Proxy
Schritt 1: Proxy einfügen
Schritt 2: Funktionalität migrieren
Schritt 3: Aufrufe umleiten
Daten?
Proxy-Optionen
Inkrementelles Roll-out
Protokolle wechseln
Service Meshes
Beispiel: FTP
Beispiel: Message Interception
Inhaltsbasiertes Routing
Selektiver Konsum
Andere Protokolle
Andere Beispiele für das Strangler Fig Pattern
Verhaltensänderung während der Migration
Pattern: UI Composition
Beispiel: Page Composition
Beispiel: Widget Composition
Mobile Anwendungen
Beispiel: Micro Frontends
Wo wir es einsetzen
Pattern: Branch by Abstraction
Wie es funktioniert
Schritt 1: Abstraktion erstellen
Schritt 2: Abstraktion verwenden
Schritt 3: Neue Implementierung erstellen
Schritt 4: Implementierung wechseln
Schritt 5: Aufräumen
Als Fallback-Mechanismus
Wo wir es einsetzen
Pattern: Parallel Run
Beispiel: Preisbildung von Kreditderivaten
Beispiel: Homegate-Angebote
Verifikationstechniken
Spione einsetzen
Scientist von GitHub
Dark Launching und Canary Releasing
Wo wir es einsetzen
Pattern: Decorating Collaborator
Beispiel: Loyalty-Programm
Wo wir es einsetzen
Pattern: Change Data Capture
Beispiel: Loyalty-Karten ausgeben
Change Data Capture implementieren
Datenbank-Trigger
Transaktionslog pollen
Batch-Delta-Kopierer
Wo wir es einsetzen
Zusammenfassung
KAPITEL 4. Die Datenbank aufteilen
Pattern: Shared Database
Hilfreiche Patterns
Wo wir es einsetzen
Aber es geht nicht!
Pattern: Database View
Die Datenbank als öffentlicher Vertrag
Präsentations-Views
Grenzen
Ownership
Wo wir es einsetzen
Pattern: Database Wrapping Service
Wo wir es einsetzen
Pattern: Database-as-a-Service Interface
Eine Mapping Engine implementieren
Vergleich mit Views
Wo wir es einsetzen
Ownership transferieren
Pattern: Aggregate Exposing Monolith
Als Weg zu weiteren Services
Wo wir es verwenden
Pattern: Change Data Ownership
Wo wir es verwenden
Datensynchronisation
Pattern: Synchronize Data in Application
Schritt 1: Daten Bulk-synchronisieren
Schritt 2: Synchrones Schreiben, aus dem alten Schema lesen
Schritt 3: Synchrones Schreiben, aus dem neuen Schema lesen
Wo dieses Pattern genutzt werden kann
Wo wir es verwenden
Pattern: Tracer Write
Datensynchronisierung
Beispiel: Bestellungen bei Square
Den neuen Service erstellen
Die Daten synchronisieren
Konsumenten migrieren
Wo wir es verwenden
Die Datenbank aufteilen
Physische versus logische Datenbanktrennung
Zuerst die Datenbank oder zuerst den Code aufteilen?
Zuerst die Datenbank aufteilen
Pattern: Repository per Bounded Context
Wo wir es verwenden
Pattern: Database per Bounded Context
Wo wir es verwenden
Zuerst den Code aufteilen
Pattern: Monolith as Data Access Layer
Wo wir es verwenden
Pattern: Multischema Storage
Wo wir es verwenden
Datenbank und Code gleichzeitig aufteilen
Was sollte ich also als Erstes aufteilen?
Beispiele zur Schemaaufteilung
Pattern: Split Table
Wo wir es verwenden
Pattern: Move Foreign-Key Relationship to Code
Den Join ersetzen
Datenkonsistenz
Vor dem Löschen prüfen
Elegant mit Löschungen umgehen
Kein Löschen erlauben
Wie sollen wir nun das Löschen handhaben?
Wo wir es verwenden
Beispiel: Gemeinsam genutzte statische Daten
Pattern: Duplicate Static Reference Data
Wo wir es verwenden
Pattern: Dedicated Reference Data Schema
Wo wir es verwenden
Pattern: Static Reference Data Library
Wo wir es verwenden
Pattern: Static Reference Data Service
Wo wir es verwenden
Was würde ich tun?
Transaktionen
ACID-Transaktionen
Weiterhin ACID, aber ohne Atomarität?
Zwei-Phasen-Commit
Verteilte Transaktionen: Sagen Sie einfach Nein!
Sagas
Fehlersituationen in Sagas
Saga-Rollbacks
Schritte für weniger Rollbacks neu ordnen
Fail-Backward- und Fail-Forward-Situationen kombinieren
Sagas implementieren
Orchestrierte Sagas
Choreografierte Sagas
Stile mischen
Sollte ich Choreografie oder Orchestrierung nutzen?
Saga versus verteilte Transaktionen
Zusammenfassung
KAPITEL 5. Wachsende Probleme
Mehr Services – mehr Schmerzen
Ownership im großen Maßstab
Wie kann sich dieses Problem zeigen?
Wann kann sich das Problem zeigen?
Mögliche Lösungen
Disruptive Änderungen
Wie kann sich dieses Problem zeigen?
Wann kann sich das Problem zeigen?
Mögliche Lösungen
Verhindern Sie unabsichtliche disruptive Änderungen
Denken Sie zweimal nach, bevor Sie eine disruptive Änderung vornehmen
Geben Sie Ihren Konsumenten Zeit, zu migrieren
Reporting
Wann kann sich dieses Problem zeigen?
Mögliche Lösungen
Monitoring und Troubleshooting
Wann kann sich dieses Problem zeigen?
Wie kann sich das Problem zeigen?
Mögliche Lösungen
Log Aggregation
Tracing
Testen im Produktivumfeld
Observability anstreben
Lokale Entwicklung
Wie kann sich dieses Problem zeigen?
Wann kann sich das Problem zeigen?
Mögliche Lösungen
Zu viele Dinge laufen lassen
Wie kann sich dieses Problem zeigen?
Wann kann sich das Problem zeigen?
Mögliche Lösungen
End-to-End-Tests
Wie kann sich dieses Problem zeigen?
Wann kann sich das Problem zeigen?
Mögliche Lösungen
Den Scope automatisierter funktionaler Tests begrenzen
Consumer-Driven Contracts einsetzen
Automatisierte Release Remediation und Progressive Delivery nutzen
Die Feedback-Zyklen zur Qualität kontinuierlich verbessern
Globale versus lokale Optimierung
Wie kann sich dieses Problem zeigen?
Wann kann sich das Problem zeigen?
Mögliche Lösungen
Robustheit und Resilienz
Wie kann sich dieses Problem zeigen?
Wann kann sich das Problem zeigen?
Mögliche Lösungen
Verwaiste Services
Wie kann sich dieses Problem zeigen?
Wann kann sich das Problem zeigen?
Mögliche Lösungen
Zusammenfassung
Abschließende Worte
ANHANG A. Literatur
ANHANG B. Pattern-Index
Fußnoten. KAPITEL 1 Gerade genug Microservices
KAPITEL 2 Eine Migration planen
KAPITEL 3 Den Monolithen aufteilen
KAPITEL 4 Die Datenbank aufteilen
KAPITEL 5 Wachsende Probleme
Index
Über den Autor
Kolophon
