|
|
|
|
LEADER |
04923nmm a2200505 u 4500 |
001 |
EB001953960 |
003 |
EBX01000000000000001116862 |
005 |
00000000000000.0 |
007 |
cr||||||||||||||||||||| |
008 |
210123 ||| ger |
020 |
|
|
|a 3960104235
|
050 |
|
4 |
|a QA76.76.A65
|
100 |
1 |
|
|a Newman, Sam
|
130 |
0 |
|
|a Monolith to microservices
|
245 |
0 |
0 |
|a Vom Monolithen zu Microservices
|h [electronic resource]
|b Patterns, um bestehende Systeme Schritt für Schritt umzugestalten
|c Sam Newman ; deutsche Übersetzung von Thomas Demmig
|
250 |
|
|
|a 1. Auflage
|
260 |
|
|
|a Heidelberg
|b O'Reilly
|c 2021
|
300 |
|
|
|a 266 pages
|
505 |
0 |
|
|a 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
|
505 |
0 |
|
|a 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
|
505 |
0 |
|
|a 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
|
505 |
0 |
|
|a 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
|
505 |
0 |
|
|a 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
|
653 |
|
|
|a Application software / Development / fast
|
653 |
|
|
|a Distributed operating systems (Computers) / http://id.loc.gov/authorities/subjects/sh90004436
|
653 |
|
|
|a Ordinateurs / Architecture
|
653 |
|
|
|a Logiciels / Modèles de conception
|
653 |
|
|
|a Systèmes d'exploitation répartis
|
653 |
|
|
|a Software patterns / http://id.loc.gov/authorities/subjects/sh98003823
|
653 |
|
|
|a Computer architecture / http://id.loc.gov/authorities/subjects/sh85029479
|
653 |
|
|
|a Application software / Development / http://id.loc.gov/authorities/subjects/sh95009362
|
653 |
|
|
|a Software patterns / fast
|
653 |
|
|
|a Computer architecture / fast
|
653 |
|
|
|a Logiciels d'application / Développement
|
653 |
|
|
|a Computer software / Development / fast
|
653 |
|
|
|a Distributed operating systems (Computers) / fast
|
653 |
|
|
|a Computer software / Development / http://id.loc.gov/authorities/subjects/sh85029535
|
700 |
1 |
|
|a Demmig, Thomas
|
041 |
0 |
7 |
|a ger
|2 ISO 639-2
|
989 |
|
|
|b OREILLY
|a O'Reilly
|
500 |
|
|
|a Description based upon print version of record
|
776 |
|
|
|z 3960104235
|
776 |
|
|
|z 9783960104230
|
856 |
4 |
0 |
|u https://learning.oreilly.com/library/view/~/9781098128234/?ar
|x Verlag
|3 Volltext
|
082 |
0 |
|
|a 005.1
|