Newman Microservices

Konzeption und Design
1. Auflage 2015
ISBN: 978-3-95845-082-0
Verlag: mitp Verlags GmbH & Co.KG
Format: PDF
Kopierschutz: 0 - No protection

E-Book, Deutsch, 312 Seiten

Reihe: mitp Professional

Feingranulare Systeme mit Microservices aufbauen
Design, Entwicklung, Deployment, Testen und Monitoring
Sicherheitsaspekte, Authentifizierung und Autorisierung

Verteilte Systeme haben sich in den letzten Jahren stark verändert: Große monolithische Architekturen werden zunehmend in viele kleine, eigenständige Microservices aufgespalten. Aber die Entwicklung solcher Systeme bringt Herausforderungen ganz eigener Art mit sich. Dieses Buch richtet sich an Softwareentwickler, die sich über die zielführenden Aspekte von Microservice-Systemen wie Design, Entwicklung, Testen, Deployment und Monitoring informieren möchten.
Sam Newman veranschaulicht und konkretisiert seine ganzheitliche Betrachtung der grundlegenden Konzepte von Microservice-Architekturen anhand zahlreicher praktischer Beispiele und Ratschläge. Er geht auf die Themen ein, mit denen sich Systemarchitekten und Administratoren bei der Einrichtung, Verwaltung und Entwicklung dieser Architekturen in jedem Fall auseinandersetzen müssen.

Aus dem Inhalt:
Vorteile von Microservices
Gestaltung von Services
Ausrichtung der Systemarchitektur an der Organisationsstruktur
Möglichkeiten zur Integration von Services
Schrittweise Aufspaltung einer monolithischen Codebasis
Deployment einzelner Microservices mittels Continuous Integration
Testen und Monitoring verteilter Systeme
Sicherheitsaspekte

Authentifizierung und Autorisierung zwischen Benutzer und Service bzw. zwischen Services untereinander
Skalierung von Microservice-Architekturen

»Microservice-Architekturen besitzen viele interessante Eigenschaften, allerdings sind bei der Umstellung so einige Fallstricke zu beachten. Dieses Buch wird Ihnen helfen herauszufinden, ob Microservices für Ihre Zwecke geeignet sind und zeigt Ihnen, wie Sie die Fallstricke umgehen können.«
Martin Fowler, Chief Scientist, ThoughtWorks

Zielgruppe

Alle Softwareentwickler, die Microservices umsetzen wollen

Autoren/Hrsg.

Newman, Sam

Inhaltsverzeichnis

1;Cover;1
2;Titel;3
3;Impressum;4
4;Inhaltsverzeichnis;5
5;Einleitung;15
6;Über den Autor;20
7;Kapitel 1: Microservices;21
7.1;1.1 Was sind Microservices?;22
7.1.1;1.1.1 Klein und darauf spezialisiert, eine bestimmte Aufgabe richtig gut zu erledigen;22
7.1.2;1.1.2 Eigenständigkeit;23
7.2;1.2 Die wichtigsten Vorteile;24
7.2.1;1.2.1 Verschiedenartige Technologien;24
7.2.2;1.2.2 Belastbarkeit;26
7.2.3;1.2.3 Skalierung;26
7.2.4;1.2.4 Komfortables Deployment;27
7.2.5;1.2.5 Betriebliche Abstimmung;28
7.2.6;1.2.6 Modularer Aufbau;28
7.2.7;1.2.7 Austauschbarkeit;29
7.3;1.3 Was ist mit serviceorientierten Architekturen?;29
7.4;1.4 Weitere Verfahren zur Aufspaltung;30
7.4.1;1.4.1 Programmbibliotheken;31
7.4.2;1.4.2 Module;31
7.5;1.5 Kein Patentrezept;33
7.6;1.6 Fazit;33
8;Kapitel 2: Der fortentwickelte Systemarchitekt;35
8.1;2.1 Unangebrachte Vergleiche;35
8.2;2.2 Das Zukunftsbild eines Systemarchitekten;37
8.3;2.3 Zoneneinteilung;39
8.4;2.4 Ein grundsätzlicher Ansatz;40
8.4.1;2.4.1 Strategische Ziele;41
8.4.2;2.4.2 Prinzipien;41
8.4.3;2.4.3 Praktiken;42
8.4.4;2.4.4 Prinzipien und Praktiken vereinigen;42
8.4.5;2.4.5 Ein Praxisbeispiel;43
8.5;2.5 Mindestvorgaben;44
8.5.1;2.5.1 Monitoring;44
8.5.2;2.5.2 Schnittstellen;45
8.5.3;2.5.3 Architektonische Sicherheit;45
8.6;2.6 Lenkung durch Code;46
8.6.1;2.6.1 Musterbeispiele;46
8.6.2;2.6.2 Maßgeschneiderte Servicevorlagen;46
8.7;2.7 Technische Schulden;48
8.8;2.8 Ausnahmebehandlung;49
8.9;2.9 Governance und Steuerung aus der Mitte;50
8.10;2.10 Aufbau eines Entwicklerteams;52
8.11;2.11 Fazit;52
9;Kapitel 3: Gestaltung von Services;55
9.1;3.1 Kurz vorgestellt: MusicCorp;55
9.2;3.2 Wodurch zeichnet sich ein guter Service aus?;56
9.2.1;3.2.1 Lose Kopplung;56
9.2.2;3.2.2 Hochgradige Geschlossenheit;56
9.3;3.3 Begrenzter Kontext;57
9.3.1;3.3.1 Geteilte und verborgene Modelle;58
9.3.2;3.3.2 Module und Services;59
9.3.3;3.3.3 Verfrühte Aufteilung;60
9.4;3.4 Funktionalitäten des Kontexts;61
9.5;3.5 Schildkröten bis ganz unten;61
9.6;3.6 Kommunikation unter geschäftlichen Aspekten;63
9.7;3.7 Der technische Rahmen;63
9.8;3.8 Fazit;65
10;Kapitel 4: Integration;67
10.1;4.1 Die Suche nach der optimalen Integrationsmethode;67
10.1.1;4.1.1 Zu Ausfällen führende Änderungen vermeiden;67
10.1.2;4.1.2 Technologieunabhängige APIs verwenden;67
10.1.3;4.1.3 Services für den Nutzer vereinfachen;68
10.1.4;4.1.4 Implementierungsdetails verbergen;68
10.2;4.2 Kundendatensätze;68
10.3;4.3 Gemeinsame Nutzung der Datenbank;69
10.4;4.4 Synchrone kontra asynchrone Kommunikation;70
10.5;4.5 Orchestrierung kontra Choreografie;72
10.6;4.6 Aufruf entfernter Prozeduren (RPC);75
10.6.1;4.6.1 Kopplung von Technologien;76
10.6.2;4.6.2 Lokale Aufrufe sind keine entfernten Aufrufe;76
10.6.3;4.6.3 Fragilität;77
10.6.4;4.6.4 Ist RPC ein Übel?;78
10.7;4.7 REST;79
10.7.1;4.7.1 REST und HTTP;80
10.7.2;4.7.2 HATEOAS;81
10.7.3;4.7.3 JSON, XML oder etwas anderes?;83
10.7.4;4.7.4 Vorsicht vor zu viel Komfort;84
10.7.5;4.7.5 Nachteile von REST über HTTP;85
10.8;4.8 Implementierung asynchroner ereignisgesteuerter Kollaboration;86
10.8.1;4.8.1 Verfügbare Technologien;86
10.8.2;4.8.2 Die Kompliziertheit asynchroner Architekturen;88
10.9;4.9 Services als Zustandsautomaten;90
10.10;4.10 Reactive Extensions;90
10.11;4.11 DRY und die Gefahren der Wiederverwendung von Code im Microservices-Umfeld;91
10.11.1;4.11.1 Client-Bibliotheken;92
10.12;4.12 Zugriff über Referenzen;93
10.13;4.13 Versionierung;95
10.13.1;4.13.1 Solange wie möglich hinauszögern;95
10.13.2;4.13.2 Zu Ausfällen führende Änderungen rechtzeitig erkennen;96
10.13.3;4.13.3 Verwendung semantischer Versionierung;97
10.13.4;4.13.4 Mehrere Endpunkte gleichzeitig betreiben;98
10.13.5;4.13.5 Mehrere Serviceversionen gleichzeitig betreiben;99
10.14;4.14 Benutzerschnittstellen;101
10.14.1;4.14.1 Zunehmend digital;101
10.14.2;4.14.2 Voraussetzungen;102
10.14.3;4.14.3 Aufbau der API;102
10.14.4;4.14.4 Bausteine der Benutzeroberfläche;104
10.14.5;4.14.5 Back-Ends für Front-Ends;106
10.14.6;4.14.6 Ein Hybridansatz;108
10.15;4.15 Integration der Software von Drittherstellern;108
10.15.1;4.15.1 Fehlende Entscheidungsmöglichkeiten;109
10.15.2;4.15.2 Anpassungen;109
10.15.3;4.15.3 Integrationswirrwarr;110
10.15.4;4.15.4 Auf sich selbst gestellt;110
10.15.5;4.15.5 Das Strangler-Pattern;113
10.16;4.16 Fazit;114
11;Kapitel 5: Die Aufspaltung des Monolithen;115
11.1;5.1 Seams;115
11.2;5.2 Aufspaltung von MusicCorp;116
11.3;5.3 Gründe zur Aufspaltung des Monolithen;117
11.3.1;5.3.1 Tempo der Änderungen;117
11.3.2;5.3.2 Teamstruktur;118
11.3.3;5.3.3 Sicherheitsaspekte;118
11.3.4;5.3.4 Technologie;118
11.4;5.4 Verwickelte Abhängigkeiten;118
11.5;5.5 Die Datenbank;119
11.6;5.6 Dem Problem zu Leibe rücken;119
11.7;5.7 Beispiel: Auflösen von Fremdschlüssel-Relationen;120
11.8;5.8 Beispiel: Statische Daten gemeinsam nutzen;122
11.9;5.9 Beispiel: Veränderliche Daten gemeinsam nutzen;123
11.10;5.10 Beispiel: Tabellen gemeinsam nutzen;125
11.11;5.11 Refactoring von Datenbanken;126
11.11.1;5.11.1 Die Aufspaltung umsetzen;126
11.12;5.12 Abgrenzung von Transaktionen;127
11.12.1;5.12.1 Versuchen Sie es später noch mal;129
11.12.2;5.12.2 Abbruch des gesamten Vorgangs;129
11.12.3;5.12.3 Verteilte Transaktionen;130
11.12.4;5.12.4 Was also tun?;131
11.13;5.13 Berichte;131
11.14;5.14 Datenbanken zur Berichterstellung;132
11.15;5.15 Datenabruf über Serviceaufrufe;134
11.16;5.16 Datenpumpen;135
11.16.1;5.16.1 Alternative Ziele;137
11.17;5.17 Ereignis-Datenpumpen;137
11.18;5.18 Backup-Datenpumpe;139
11.19;5.19 Benachrichtigung in Echtzeit;139
11.20;5.20 Änderungen verursachen Aufwand;140
11.21;5.21 Erkennen der eigentlichen Ursachen;141
11.22;5.22 Fazit;141
12;Kapitel 6: Deployment;143
12.1;6.1 Continuous Integration für Einsteiger;143
12.1.1;6.1.1 Machen Sie es auch richtig?;144
12.2;6.2 Continuous Integration und Microservices;145
12.3;6.3 Build Pipelines und Continuous Delivery;148
12.3.1;6.3.1 Die unvermeidlichen Ausnahmen;149
12.4;6.4 Plattformspezifische Artefakte;150
12.5;6.5 Betriebssystemspezifische Artefakte;151
12.6;6.6 Selbsterstellte Images;152
12.6.1;6.6.1 Images als Artefakte;154
12.6.2;6.6.2 Unveränderliche Server;155
12.7;6.7 Umgebungen;155
12.7.1;6.7.1 Servicekonfiguration;157
12.7.2;6.7.2 Zuordnung der Services zu den Hosts;158
12.7.3;6.7.3 Mehrere Services pro Host;158
12.7.4;6.7.4 Anwendungscontainer;161
12.7.5;6.7.5 Ein Service pro Host;162
12.7.6;6.7.6 Platform-as-a-Service (PaaS);163
12.8;6.8 Automatisierung;164
12.8.1;6.8.1 Zwei Fallstudien zur Leistungsfähigkeit der Automatisierung;165
12.9;6.9 Physisch wird virtuell;166
12.9.1;6.9.1 Herkömmliche Virtualisierung;166
12.9.2;6.9.2 Vagrant;168
12.9.3;6.9.3 Linux-Container;168
12.9.4;6.9.4 Docker;170
12.10;6.10 Schnittstelle für das Deployment;171
12.10.1;6.10.1 Definition der Umgebung;173
12.11;6.11 Fazit;174
13;Kapitel 7: Testen;177
13.1;7.1 Testtypen;177
13.2;7.2 Testumfang;178
13.2.1;7.2.1 Unit-Tests;180
13.2.2;7.2.2 Servicetests;181
13.2.3;7.2.3 End-to-End-Tests;182
13.2.4;7.2.4 Nachteile;182
13.2.5;7.2.5 Wie viele Tests?;183
13.3;7.3 Implementierung von Servicetests;183
13.3.1;7.3.1 Mock-Objekte kontra Platzhalter;184
13.3.2;7.3.2 Ein intelligenterer Platzhalterservice;185
13.4;7.4 Knifflige End-to-End-Tests;185
13.5;7.5 Nachteile von End-to-End-Tests;187
13.5.1;7.5.1 Unzuverlässige und fragile Tests;187
13.5.2;7.5.2 Wer programmiert die Tests?;188
13.5.3;7.5.3 Testdauer;189
13.5.4;7.5.4 Das große Auftürmen;190
13.5.5;7.5.5 Die Metaversion;191
13.6;7.6 Abläufe testen, nicht Funktionalitäten;191
13.7;7.7 Abhilfe durch Consumer-Driven Tests;192
13.7.1;7.7.1 Pact;194
13.7.2;7.7.2 Konversationen;195
13.8;7.8 End-to-End-Tests: Pro und Kontra;196
13.9;7.9 Testen nach der Veröffentlichung;196
13.9.1;7.9.1 Deployment und Veröffentlichung trennen;197
13.9.2;7.9.2 Canary-Veröffentlichung;198
13.9.3;7.9.3 MTTR kontra MTBR;200
13.10;7.10 Funktionsübergreifende Tests;201
13.10.1;7.10.1 Geschwindigkeitstests;202
13.11;7.11 Fazit;203
14;Kapitel 8: Monitoring;205
14.1;8.1 Ein Service, ein Server;206
14.2;8.2 Ein Service, mehrere Server;207
14.3;8.3 Mehrere Services, mehrere Server;208
14.4;8.4 Protokolle, Protokolle und noch mehr Protokolle;208
14.5;8.5 Kennzahlen mehrerer Services;209
14.6;8.6 Servicekennzahlen;211
14.7;8.7 Monitoringung von Pseudo-Ereignissen;212
14.7.1;8.7.1 Implementierung des semantischen Monitorings;213
14.8;8.8 Korrelations-IDs;213
14.9;8.9 Die Aufrufkette;216
14.10;8.10 Standardisierung;216
14.11;8.11 Zielgruppen;217
14.12;8.12 Wie geht es weiter?;218
14.13;8.13 Fazit;219
15;Kapitel 9: Sicherheit;221
15.1;9.1 Authentifizierung und Autorisierung;221
15.1.1;9.1.1 Gängige Single-Sign-On-Implementierungen;222
15.1.2;9.1.2 Single-Sign-On-Gateway;223
15.1.3;9.1.3 Fein unterteilte Authentifizierung;225
15.2;9.2 Authentifizierung und Autorisierung von Services;226
15.2.1;9.2.1 Im internen Netzwerk ist alles erlaubt;226
15.2.2;9.2.2 Authentifizierung über HTTP(S);226
15.2.3;9.2.3 Verwendung von SAML oder OpenID Connect;227
15.2.4;9.2.4 Client-Zertifikate;228
15.2.5;9.2.5 HMAC über HTTP;229
15.2.6;9.2.6 API-Schlüssel;230
15.2.7;9.2.7 Das Stellvertreterproblem;231
15.3;9.3 Schutz ruhender Daten;233
15.3.1;9.3.1 Wohlbekannte Verfahren einsetzen;234
15.3.2;9.3.2 Die Bedeutung der Schlüssel;235
15.3.3;9.3.3 Was soll verschlüsselt werden?;235
15.3.4;9.3.4 Entschlüsselung bei Bedarf;236
15.3.5;9.3.5 Backups verschlüsseln;236
15.4;9.4 Gestaffelte Sicherheitsstrategie;236
15.4.1;9.4.1 Firewalls;236
15.4.2;9.4.2 Protokollierung;236
15.4.3;9.4.3 Intrusion-Detection-Systeme;237
15.4.4;9.4.4 Unterteilung des Netzwerks;237
15.4.5;9.4.5 Betriebssystem;238
15.5;9.5 Ein ausgearbeitetes Beispiel;239
15.6;9.6 Datensparsamkeit;241
15.7;9.7 Der Faktor Mensch;242
15.8;9.8 Eine Goldene Regel;242
15.9;9.9 Integrierte Sicherheit;243
15.10;9.10 Externe Prüfung;243
15.11;9.11 Fazit;244
16;Kapitel 10: Conways Gesetz und Systemdesign;245
16.1;10.1 Beweise;245
16.1.1;10.1.1 Lose und eng gekoppelte Organisationen;246
16.1.2;10.1.2 Windows Vista;246
16.2;10.2 Netflix und Amazon;246
16.3;10.3 Was kann man damit anfangen?;247
16.4;10.4 Anpassung an Kommunikationswege;247
16.5;10.5 Verantwortlichkeit für Services;249
16.6;10.6 Gemeinschaftliche Verantwortlichkeit für Services;249
16.6.1;10.6.1 Schwierige Aufspaltung;249
16.6.2;10.6.2 Feature-Teams;250
16.6.3;10.6.3 Engpässe bei der Auslieferung;250
16.7;10.7 Interner Open-Source-Code;251
16.7.1;10.7.1 Aufgaben der Koordinatoren;252
16.7.2;10.7.2 Ausgereifte Services;253
16.7.3;10.7.3 Werkzeugsammlungen;253
16.8;10.8 Begrenzte Kontexte und Teamstrukturen;253
16.9;10.9 Verwaiste Services?;254
16.10;10.10 Fallstudie: RealEstate.com.au;254
16.11;10.11 Conways Gesetz auf den Kopf gestellt;256
16.12;10.12 Menschen;257
16.13;10.13 Fazit;258
17;Kapitel 11: Microservices skalieren;259
17.1;11.1 Ausfälle gibt es immer;259
17.2;11.2 Wie viel ist zu viel?;260
17.3;11.3 Schrittweiser Abbau der Funktionalität;261
17.4;11.4 Architektonische Sicherheitsmaßnahmen;262
17.5;11.5 Die antifragile Organisation;265
17.5.1;11.5.1 Timeouts;266
17.5.2;11.5.2 Circuit Breaker;266
17.5.3;11.5.3 Das Bulkhead-Pattern;269
17.5.4;11.5.4 Isolierung;270
17.6;11.6 Idempotenz;270
17.7;11.7 Skalierung;272
17.7.1;11.7.1 Mehr Leistung;272
17.7.2;11.7.2 Arbeitslast aufteilen;273
17.7.3;11.7.3 Risikoverteilung;273
17.7.4;11.7.4 Lastverteilung;274
17.7.5;11.7.5 Worker-Systeme;276
17.7.6;11.7.6 Neuanfang;277
17.8;11.8 Datenbanken skalieren;278
17.8.1;11.8.1 Verfügbarkeit des Services kontra Lebensdauer der Daten;278
17.8.2;11.8.2 Skalierung bei Lesevorgängen;279
17.8.3;11.8.3 Skalierung bei Schreibvorgängen;280
17.8.4;11.8.4 Gemeinsam genutzte Datenbankinfrastruktur;281
17.8.5;11.8.5 CQRS;281
17.9;11.9 Caching;282
17.9.1;11.9.1 Clientseitiges Caching, Proxy und serverseitiges Caching;283
17.9.2;11.9.2 Caching und HTTP;284
17.9.3;11.9.3 Caching bei Schreibvorgängen;285
17.9.4;11.9.4 Caching zur Erhöhung der Belastbarkeit;286
17.9.5;11.9.5 Den Ursprung verbergen;286
17.9.6;11.9.6 Möglichst einfach;287
17.9.7;11.9.7 Cache Poisoning: Ein warnendes Beispiel;288
17.10;11.10 Automatische Skalierung;289
17.11;11.11 Das CAP-Theorem;290
17.11.1;11.11.1 Aufgabe der Konsistenz;292
17.11.2;11.11.2 Aufgabe der Verfügbarkeit;292
17.11.3;11.11.3 Aufgabe der Partitionstoleranz?;294
17.11.4;11.11.4 AP oder CP?;294
17.11.5;11.11.5 Keine Frage eines Entweder-Oders;294
17.11.6;11.11.6 Abbildung der Wirklichkeit;295
17.12;11.12 Serviceerkennung;296
17.12.1;11.12.1 DNS;296
17.13;11.13 Dynamische Registrierung von Services;298
17.13.1;11.13.1 Zookeeper;298
17.13.2;11.13.2 Consul;300
17.13.3;11.13.3 Eureka;301
17.13.4;11.13.4 Eigene Serviceregistrierung;301
17.13.5;11.13.5 Menschliches Interesse;302
17.14;11.14 Services dokumentieren;302
17.14.1;11.14.1 Swagger;302
17.14.2;11.14.2 HAL und der HAL-Browser;303
17.15;11.15 Ein sich selbst beschreibendes System;304
17.16;11.16 Fazit;305
18;Kapitel 12: Auf den Punkt gebracht;307
18.1;12.1 Prinzipien;307
18.1.1;12.1.1 Geschäftsvorgänge modellieren;308
18.1.2;12.1.2 Automatisierung kultivieren;308
18.1.3;12.1.3 Implementierungsdetails verbergen;309
18.1.4;12.1.4 Dezentralisierung;309
18.1.5;12.1.5 Unabhängiges Deployment;310
18.1.6;12.1.6 Ausfälle eingrenzen;310
18.1.7;12.1.7 Umfassendes Monitoring;311
18.2;12.2 Wann sollte man auf Microservices verzichten?;311
18.3;12.3 Schlusswort;312
19;Stichwortverzeichnis;313

Leseproben

Einleitung
Microservices sind ein Ansatz für verteilte Systeme, die die Nutzung feingranularer Services mit eigenen Entwicklungszyklen fördern, die sich gegenseitig zuarbeiten. Da Microservices vornehmlich im geschäftlichen Umfeld Anwendung finden, werden die bei herkömmlichen abgestuften Architekturen auftretenden Schwierigkeiten umgangen. Microservices nutzen außerdem die während des letzten Jahrzehnts entwickelten Technologien und Verfahren und vermeiden dadurch die Fallstricke, die mit vielen serviceorientierten Architekturen einhergehen. Dieses Buch enthält eine Reihe konkreter Beispiele dafür, wie Microservices weltweit eingesetzt werden, etwa in Unternehmen wie Netflix, Amazon, Gilt und der REA-Gruppe, die allesamt festgestellt haben, dass ihnen die erhöhte Unabhängigkeit dieser Architektur große Vorteile bringt. Wer sollte dieses Buch lesen?
Der Anwendungsbereich dieses Buches umfasst ein breites Spektrum, ebenso wie auch die Auswirkungen einer feingranularen Microservice-Architektur vielgestaltig sind. Es soll Leser ansprechen, die an verschiedenen Aspekten des Designs, der Entwicklung, des Deployments, des Testens und der Wartung dieser Systeme interessiert sind. Diejenigen Leser, die bereits damit begonnen haben, sich mit feiner unterteilten Architekturen zu beschäftigen – sei es nun einer vollkommen neuen Anwendung oder der Aufteilung eines bereits vorhandenen, eher monolithischen Systems –, werden viele praktische Ratschläge finden. Und auch denjenigen Lesern, die im Grunde nur wissen möchten, was der ganze Rummel eigentlich soll, wird geholfen, damit sie entscheiden können, ob Microservices für ihre Zwecke geeignet sind. Der Grund für dieses Buch
Als es vor vielen Jahren zu meinen Aufgaben gehörte, anderen dabei zu helfen, Software schneller fertigzustellen, fing ich an, mich mit Anwendungsarchitekturen zu befassen. Mir war klar, dass automatisierte Infrastrukturen, Tests und kontinuierliche Weiterentwicklungen zwar durchaus hilfreich sind, man aber bald an die Grenzen des Machbaren stößt, wenn das grundlegende Design eines Systems es nicht erlaubt, schnell und einfach Modifizierungen daran vorzunehmen. Zur selben Zeit experimentierten viele Unternehmen mit feiner unterteilten Architekturen, um vergleichbare Ergebnisse zu erzielen. Gleichzeitig sollten aber auch eine verbesserte Skalierbarkeit, eine größere Unabhängigkeit der Entwicklerteams oder eine vereinfachte Übernahme neuer Technologien ermöglicht werden. Sowohl meine eigenen Erfahrungen als auch die meiner Kollegen bei ThoughtWorks und anderen Unternehmen bestätigten die Tatsache, dass eine größere Zahl eingesetzter unabhängiger Services mit eigenen Entwicklungszyklen unweigerlich zu weiteren Problemen führt, mit denen man sich auseinandersetzen muss. Dieses Buch soll in gewisser Weise eine Art zentrale Anlaufstelle sein und helfen, die breite Palette von Themen, die zum Verständnis von Microservices nötig ist, zu beschreiben. So etwas hätte mir seinerzeit wirklich außerordentlich geholfen! Zum Stand der Dinge
Das Thema »Microservices« ist einem ständigen Wandel unterworfen. Obwohl die Idee an sich nicht neu ist (auch wenn der Begriff es ist), haben die Erfahrungen der Nutzer auf der ganzen Welt zusammen mit dem Aufkommen neuer Technologien maßgeblichen Einfluss auf die Verwendungsweise. Aufgrund der schnellen Fortentwicklung in diesem Bereich habe ich versucht, mich in den folgenden Kapiteln weniger auf bestimmte Technologien als vielmehr auf die grundlegenden Konzepte zu konzentrieren, und zwar wohlwissend, dass sich Details der Implementierung stets schneller ändern als die dahinterstehenden Ideen. Dessen ungeachtet erwarte ich absolut, dass wir in einigen Jahren noch besser verstehen werden, wann der Einsatz von Microservices angebracht ist und wie sie vernünftigerweise eingesetzt werden. Aufbau des Buches
Der Aufbau dieses Buches orientiert sich vornehmlich an den behandelten Themen. Sie können daher direkt zu einem bestimmten Thema springen, das Sie am meisten interessiert. Ich habe mich bemüht, wichtige Begriffe und Konzepte gleich in den ersten Kapiteln zu erläutern und gehe davon aus, dass selbst Leser, die sich als recht erfahren einschätzen, in jedem Kapitel noch etwas von Interesse entdecken. Grundsätzlich empfehle ich Ihnen, sich Kapitel 2 anzusehen, das einen Eindruck von der Tiefe des Themas vermittelt und umreißt, wie ich im weiteren Verlauf des Buches vorgehe, falls Sie sich mit den nachfolgenden Inhalten eingehender beschäftigen möchten. Ich hoffe, ich habe die Kapitel für Leser, denen das Thema neu ist, in der richtigen Reihenfolge angeordnet, damit das Buch in sinnvoller Weise von vorn bis hinten durchgelesen werden kann. Hier ein Überblick über den Inhalt des Buches: Kapitel 1 – Microservices Wir beginnen mit einer Einführung in das Thema Microservices, in der die wesentlichen Vorteile, aber auch einige der Nachteile dargestellt werden. Kapitel 2 – Der fortentwickelte Systemarchitekt In diesem Kapitel kommen die Schwierigkeiten zur Sprache, denen man als Systemarchitekt gegenübersteht, weil man Kompromisse eingehen muss. Außerdem wird erörtert, was bei der Verwendung von Microservices alles zu beachten ist. Kapitel 3 – Gestaltung von Services Hier werden die Grenzen der Microservices erkundet. Um uns auf das Wesentliche zu konzentrieren, kommen dabei Verfahren des vom Anwendungsbereich geprägten Designs (Domain-Driven Design?, D?DD) zum Einsatz. Kapitel 4 – Integration An dieser Stelle beschäftigen wir uns eingehender mit bestimmten Auswirkungen der Technologien und erörtern, welche Arten der Zusammenarbeit von Services am nützlichsten sind. Des Weiteren werden wir auf die Themen Benutzerschnittstelle und Integration vorhandener und seriengefertigter Produkte (Commercial off-the-shel?f ,? COTS) eingehen. Kapitel 5 – Die Aufspaltung des Monolithen In vielen Fällen richtet sich das Interesse auf die Microservices, um sie in großen, nur schwer änderbaren monolithischen Systemen sozusagen als Gegenmittel einzusetzen. Genau dieser Ansatz wird in diesem Kapitel ausführlich untersucht. Kapitel 6 – Deployment Das Buch ist zwar weitgehend theoretischer Natur, allerdings wurde kaum ein anderes der behandelten Themen so sehr durch die jüngsten technologischen Neuerungen beeinflusst wie das Deployment. Dieser Aspekt wird hier eingehender betrachtet. Kapitel 7 – Testen Dieses Kapitel geht dem Thema Testen auf den Grund – einem Bereich, der gerade beim Deployment mehrerer eigenständiger Services von Bedeutung ist. Besonders interessant ist hier die Rolle, die Consumer-Driven Contracts? (CDC?s) für die Gewährleistung der Qualität unserer Software spielen. Kapitel 8 – Monitoring Die vor der Auslieferung durchgeführten Tests helfen uns nicht weiter, wenn Probleme erst auftreten, nachdem die Software bereits online gestellt wurde. In diesem Kapitel wird untersucht, wie sich verteilte Systeme überwachen lassen und wie man die bei solchen Systemen auftretende Komplexität handhabt. Kapitel 9 – Sicherheit Hier betrachten wir die Sicherheitsaspekte von Microservices und untersuchen, wie Authentifizierung und Autorisierung zwischen Benutzer und Service bzw. zwischen Services gehandhabt werden. Sicherheit ist ein sehr wichtiges Thema, das allzu leicht vernachlässigt wird. Ich bin zwar keineswegs ein Sicherheitsexperte, hoffe jedoch, dass dieses Kapitel Ihnen dabei hilft, beim Aufbau Ihrer Systeme bedeutsame Sicherheitsaspekte in Betracht zu ziehen – insbesondere, wenn es sich um Microservice-Systeme handelt. Kapitel 10 – Conways Gesetz und Systemdesign Dieses Kapitel widmet sich dem Zusammenspiel zwischen Organisationsstruktur und Systemarchitektur. Wie viele Unternehmen bereits feststellen mussten, führt es zu Problemen, wenn diese beiden Faktoren nicht aufeinander abgestimmt sind. Wir werden versuchen, die Ursachen dieses Dilemmas zu erörtern und betrachten verschiedene Möglichkeiten, das Systemdesign an die Struktur des Entwicklerteams anzugleichen. Kapitel 11 – Microservices skalieren Hier werden wir uns ansehen, wie Microservices skalieren, damit wir die bei einer großen Zahl von Services und hohem Datenaufkommen wachsende Wahrscheinlichkeit eines Systemausfalls handhaben können. Kapitel 12 – Auf den Punkt gebracht Das letzte Kapitel bemüht sich, die Besonderheiten von Microservices hervorzuheben. Es enthält eine Liste von sieben für Microservices geltende Prinzipien und arbeitet die Kernpunkte des Buches heraus. Konventionen dieses Buches
In diesem Buch gelten folgende typografische Konventionen: Neue Begriffe, Dateinamen und Dateinamenerweiterungen sind kursiv gedruckt. URLs und...

Über Autor(innen)

Sam Newman ist als Technologist bei ThoughtWorks tätig, wo er einerseits als Berater arbeitet und andererseits auch als Systemarchitekt für die unternehmenseigenen Systeme verantwortlich ist. Im Rahmen seiner Beratertätigkeit arbeitete er mit zahlreichen weltweit tätigen Unternehmen aus den unterschiedlichsten Geschäftsbereichen sowohl im Bereich der Entwicklung als auch des Betriebs von Microservice-Architekturen zusammen.