1 option
Vom Monolithen zu Microservices / Newman, Sam.
- Format:
- Book
- Author/Creator:
- Newman, Sam, author.
- Language:
- English
- German
- Subjects (All):
- Migration.
- Softwareentwicklung.
- Datenbank.
- Softwarearchitektur.
- Refactoring.
- Legacy-Systeme.
- Refaktorisierung.
- Sam Newman.
- Datenbankmigration.
- Physical Description:
- 1 online resource (266 pages)
- Edition:
- 1st edition
- Place of Publication:
- dpunkt, 2020.
- System Details:
- text file
- Summary:
- Bestehende Systeme erfolgreich in eine Microservices-Architektur umgestalten
- Contents:
- 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
- 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
- Pattern: Branch by Abstraction
- Als Fallback-Mechanismus
- Pattern: Parallel Run
- Beispiel: Preisbildung von Kreditderivaten
- Beispiel: Homegate-Angebote
- Verifikationstechniken
- Spione einsetzen
- Scientist von GitHub
- Dark Launching und Canary Releasing
- Pattern: Decorating Collaborator
- Beispiel: Loyalty-Programm
- Pattern: Change Data Capture
- Beispiel: Loyalty-Karten ausgeben
- Change Data Capture implementieren
- 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
- Pattern: Database Wrapping Service
- Pattern: Database-as-a-Service Interface
- Eine Mapping Engine implementieren
- Vergleich mit Views
- 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
- 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
- Pattern: Move Foreign-Key Relationship to Code
- Den Join ersetzen
- Datenkonsistenz
- 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
- 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?
- Reporting
- Wann kann sich dieses Problem zeigen?
- Monitoring und Troubleshooting
- Wie kann sich das Problem zeigen?
- Lokale Entwicklung
- Zu viele Dinge laufen lassen
- End-to-End-Tests
- Globale versus lokale Optimierung
- Robustheit und Resilienz
- Verwaiste Services
- Abschließende Worte
- Anhang A: Literatur
- Anhang B: Pattern-Index
- Index.
- Notes:
- Online resource; Title from title page (viewed October 28, 2020)
- PublicationDate: 20201015
- Description based on publisher supplied metadata and other sources.
- ISBN:
- 9781098128234
- 1098128230
- 9783960104230
- 3960104235
- OCLC:
- 1202480493
The Penn Libraries is committed to describing library materials using current, accurate, and responsible language. If you discover outdated or inaccurate language, please fill out this feedback form to report it and suggest alternative language.