Vom Monolithen zu Microservices
Bestehende Systeme erfolgreich in eine Microservices-Architektur umgestalten
| Otros Autores: | , |
|---|---|
| Formato: | Libro electrónico |
| Idioma: | Inglés |
| Publicado: |
dpunkt
2020.
|
| Edición: | 1st edition |
| Materias: | |
| Ver en Biblioteca Universitat Ramon Llull: | https://discovery.url.edu/permalink/34CSUC_URL/1im36ta/alma991009630800906719 |
Tabla de Contenidos:
- Intro
- Inhalt
- Vorwort
- 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
- Der verteilte Monolith
- Black-Box-Systeme von Fremdherstellern
- Herausforderungen von Monolithen
- Vorteile von Monolithen
- Zu Kopplung und Kohäsion
- Kohäsion
- Kopplung
- 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
- Time-to-Market verringern
- Kostengünstig auf Last reagieren
- Robustheit verbessern
- Die Anzahl der Entwickler erhöhen
- Neue Technologien einsetzen
- 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
- Migrations-Patterns
- Pattern: Strangler Fig Application
- Wie es funktioniert
- Wo wir es einsetzen
- Beispiel: HTTP Reverse Proxy
- Daten?
- Proxy-Optionen
- Protokolle wechseln
- Beispiel: FTP
- Beispiel: Message Interception
- 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
- Beispiel: Micro Frontends
- Wo wir es einsetzen
- Pattern: Branch by Abstraction
- Wie es funktioniert
- 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
- 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
- Pattern: Change Data Ownership
- 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
- Wo wir es verwenden
- Die Datenbank aufteilen
- Physische versus logische Datenbanktrennung
- Zuerst die Datenbank oder zuerst den Code aufteilen?
- Zuerst die Datenbank aufteilen
- Zuerst den Code aufteilen
- 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
- Wo wir es verwenden
- Beispiel: Gemeinsam genutzte statische Daten
- Transaktionen
- ACID-Transaktionen
- Weiterhin ACID, aber ohne Atomarität?
- Zwei-Phasen-Commit
- Verteilte Transaktionen: Sagen Sie einfach Nein!
- Sagas
- Fehlersituationen in Sagas
- Sagas implementieren
- 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
- 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
- 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
- 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
- Index.
