Microservices (mitp Professional) (eBook)
312 Seiten
MITP Verlags GmbH & Co. KG
978-3-95845-082-0 (ISBN)
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.
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.
Cover 1
Titel 3
Impressum 4
Inhaltsverzeichnis 5
Einleitung 15
Über den Autor 20
Kapitel 1: Microservices 21
1.1 Was sind Microservices? 22
1.1.1 Klein und darauf spezialisiert, eine bestimmte Aufgabe richtig gut zu erledigen 22
1.1.2 Eigenständigkeit 23
1.2 Die wichtigsten Vorteile 24
1.2.1 Verschiedenartige Technologien 24
1.2.2 Belastbarkeit 26
1.2.3 Skalierung 26
1.2.4 Komfortables Deployment 27
1.2.5 Betriebliche Abstimmung 28
1.2.6 Modularer Aufbau 28
1.2.7 Austauschbarkeit 29
1.3 Was ist mit serviceorientierten Architekturen? 29
1.4 Weitere Verfahren zur Aufspaltung 30
1.4.1 Programmbibliotheken 31
1.4.2 Module 31
1.5 Kein Patentrezept 33
1.6 Fazit 33
Kapitel 2: Der fortentwickelte Systemarchitekt 35
2.1 Unangebrachte Vergleiche 35
2.2 Das Zukunftsbild eines Systemarchitekten 37
2.3 Zoneneinteilung 39
2.4 Ein grundsätzlicher Ansatz 40
2.4.1 Strategische Ziele 41
2.4.2 Prinzipien 41
2.4.3 Praktiken 42
2.4.4 Prinzipien und Praktiken vereinigen 42
2.4.5 Ein Praxisbeispiel 43
2.5 Mindestvorgaben 44
2.5.1 Monitoring 44
2.5.2 Schnittstellen 45
2.5.3 Architektonische Sicherheit 45
2.6 Lenkung durch Code 46
2.6.1 Musterbeispiele 46
2.6.2 Maßgeschneiderte Servicevorlagen 46
2.7 Technische Schulden 48
2.8 Ausnahmebehandlung 49
2.9 Governance und Steuerung aus der Mitte 50
2.10 Aufbau eines Entwicklerteams 52
2.11 Fazit 52
Kapitel 3: Gestaltung von Services 55
3.1 Kurz vorgestellt: MusicCorp 55
3.2 Wodurch zeichnet sich ein guter Service aus? 56
3.2.1 Lose Kopplung 56
3.2.2 Hochgradige Geschlossenheit 56
3.3 Begrenzter Kontext 57
3.3.1 Geteilte und verborgene Modelle 58
3.3.2 Module und Services 59
3.3.3 Verfrühte Aufteilung 60
3.4 Funktionalitäten des Kontexts 61
3.5 Schildkröten bis ganz unten 61
3.6 Kommunikation unter geschäftlichen Aspekten 63
3.7 Der technische Rahmen 63
3.8 Fazit 65
Kapitel 4: Integration 67
4.1 Die Suche nach der optimalen Integrationsmethode 67
4.1.1 Zu Ausfällen führende Änderungen vermeiden 67
4.1.2 Technologieunabhängige APIs verwenden 67
4.1.3 Services für den Nutzer vereinfachen 68
4.1.4 Implementierungsdetails verbergen 68
4.2 Kundendatensätze 68
4.3 Gemeinsame Nutzung der Datenbank 69
4.4 Synchrone kontra asynchrone Kommunikation 70
4.5 Orchestrierung kontra Choreografie 72
4.6 Aufruf entfernter Prozeduren (RPC) 75
4.6.1 Kopplung von Technologien 76
4.6.2 Lokale Aufrufe sind keine entfernten Aufrufe 76
4.6.3 Fragilität 77
4.6.4 Ist RPC ein Übel? 78
4.7 REST 79
4.7.1 REST und HTTP 80
4.7.2 HATEOAS 81
4.7.3 JSON, XML oder etwas anderes? 83
4.7.4 Vorsicht vor zu viel Komfort 84
4.7.5 Nachteile von REST über HTTP 85
4.8 Implementierung asynchroner ereignisgesteuerter Kollaboration 86
4.8.1 Verfügbare Technologien 86
4.8.2 Die Kompliziertheit asynchroner Architekturen 88
4.9 Services als Zustandsautomaten 90
4.10 Reactive Extensions 90
4.11 DRY und die Gefahren der Wiederverwendung von Code im Microservices-Umfeld 91
4.11.1 Client-Bibliotheken 92
4.12 Zugriff über Referenzen 93
4.13 Versionierung 95
4.13.1 Solange wie möglich hinauszögern 95
4.13.2 Zu Ausfällen führende Änderungen rechtzeitig erkennen 96
4.13.3 Verwendung semantischer Versionierung 97
4.13.4 Mehrere Endpunkte gleichzeitig betreiben 98
4.13.5 Mehrere Serviceversionen gleichzeitig betreiben 99
4.14 Benutzerschnittstellen 101
4.14.1 Zunehmend digital 101
4.14.2 Voraussetzungen 102
4.14.3 Aufbau der API 102
4.14.4 Bausteine der Benutzeroberfläche 104
4.14.5 Back-Ends für Front-Ends 106
4.14.6 Ein Hybridansatz 108
4.15 Integration der Software von Drittherstellern 108
4.15.1 Fehlende Entscheidungsmöglichkeiten 109
4.15.2 Anpassungen 109
4.15.3 Integrationswirrwarr 110
4.15.4 Auf sich selbst gestellt 110
4.15.5 Das Strangler-Pattern 113
4.16 Fazit 114
Kapitel 5: Die Aufspaltung des Monolithen 115
5.1 Seams 115
5.2 Aufspaltung von MusicCorp 116
5.3 Gründe zur Aufspaltung des Monolithen 117
5.3.1 Tempo der Änderungen 117
5.3.2 Teamstruktur 118
5.3.3 Sicherheitsaspekte 118
5.3.4 Technologie 118
5.4 Verwickelte Abhängigkeiten 118
5.5 Die Datenbank 119
5.6 Dem Problem zu Leibe rücken 119
5.7 Beispiel: Auflösen von Fremdschlüssel-Relationen 120
5.8 Beispiel: Statische Daten gemeinsam nutzen 122
5.9 Beispiel: Veränderliche Daten gemeinsam nutzen 123
5.10 Beispiel: Tabellen gemeinsam nutzen 125
5.11 Refactoring von Datenbanken 126
5.11.1 Die Aufspaltung umsetzen 126
5.12 Abgrenzung von Transaktionen 127
5.12.1 Versuchen Sie es später noch mal 129
5.12.2 Abbruch des gesamten Vorgangs 129
5.12.3 Verteilte Transaktionen 130
5.12.4 Was also tun? 131
5.13 Berichte 131
5.14 Datenbanken zur Berichterstellung 132
5.15 Datenabruf über Serviceaufrufe 134
5.16 Datenpumpen 135
5.16.1 Alternative Ziele 137
5.17 Ereignis-Datenpumpen 137
5.18 Backup-Datenpumpe 139
5.19 Benachrichtigung in Echtzeit 139
5.20 Änderungen verursachen Aufwand 140
5.21 Erkennen der eigentlichen Ursachen 141
5.22 Fazit 141
Kapitel 6: Deployment 143
6.1 Continuous Integration für Einsteiger 143
6.1.1 Machen Sie es auch richtig? 144
6.2 Continuous Integration und Microservices 145
6.3 Build Pipelines und Continuous Delivery 148
6.3.1 Die unvermeidlichen Ausnahmen 149
6.4 Plattformspezifische Artefakte 150
6.5 Betriebssystemspezifische Artefakte 151
6.6 Selbsterstellte Images 152
6.6.1 Images als Artefakte 154
6.6.2 Unveränderliche Server 155
6.7 Umgebungen 155
6.7.1 Servicekonfiguration 157
6.7.2 Zuordnung der Services zu den Hosts 158
6.7.3 Mehrere Services pro Host 158
6.7.4 Anwendungscontainer 161
6.7.5 Ein Service pro Host 162
6.7.6 Platform-as-a-Service (PaaS) 163
6.8 Automatisierung 164
6.8.1 Zwei Fallstudien zur Leistungsfähigkeit der Automatisierung 165
6.9 Physisch wird virtuell 166
6.9.1 Herkömmliche Virtualisierung 166
6.9.2 Vagrant 168
6.9.3 Linux-Container 168
6.9.4 Docker 170
6.10 Schnittstelle für das Deployment 171
6.10.1 Definition der Umgebung 173
6.11 Fazit 174
Kapitel 7: Testen 177
7.1 Testtypen 177
7.2 Testumfang 178
7.2.1 Unit-Tests 180
7.2.2 Servicetests 181
7.2.3 End-to-End-Tests 182
7.2.4 Nachteile 182
7.2.5 Wie viele Tests? 183
7.3 Implementierung von Servicetests 183
7.3.1 Mock-Objekte kontra Platzhalter 184
7.3.2 Ein intelligenterer Platzhalterservice 185
7.4 Knifflige End-to-End-Tests 185
7.5 Nachteile von End-to-End-Tests 187
7.5.1 Unzuverlässige und fragile Tests 187
7.5.2 Wer programmiert die Tests? 188
7.5.3 Testdauer 189
7.5.4 Das große Auftürmen 190
7.5.5 Die Metaversion 191
7.6 Abläufe testen, nicht Funktionalitäten 191
7.7 Abhilfe durch Consumer-Driven Tests 192
7.7.1 Pact 194
7.7.2 Konversationen 195
7.8 End-to-End-Tests: Pro und Kontra 196
7.9 Testen nach der Veröffentlichung 196
7.9.1 Deployment und Veröffentlichung trennen 197
7.9.2 Canary-Veröffentlichung 198
7.9.3 MTTR kontra MTBR 200
7.10 Funktionsübergreifende Tests 201
7.10.1 Geschwindigkeitstests 202
7.11 Fazit 203
Kapitel 8: Monitoring 205
8.1 Ein Service, ein Server 206
8.2 Ein Service, mehrere Server 207
8.3 Mehrere Services, mehrere Server 208
8.4 Protokolle, Protokolle und noch mehr Protokolle 208
8.5 Kennzahlen mehrerer Services 209
8.6 Servicekennzahlen 211
8.7 Monitoringung von Pseudo-Ereignissen 212
8.7.1 Implementierung des semantischen Monitorings 213
8.8 Korrelations-IDs 213
8.9 Die Aufrufkette 216
8.10 Standardisierung 216
8.11 Zielgruppen 217
8.12 Wie geht es weiter? 218
8.13 Fazit 219
Kapitel 9: Sicherheit 221
9.1 Authentifizierung und Autorisierung 221
9.1.1 Gängige Single-Sign-On-Implementierungen 222
9.1.2 Single-Sign-On-Gateway 223
9.1.3 Fein unterteilte Authentifizierung 225
9.2 Authentifizierung und Autorisierung von Services 226
9.2.1 Im internen Netzwerk ist alles erlaubt 226
9.2.2 Authentifizierung über HTTP(S) 226
9.2.3 Verwendung von SAML oder OpenID Connect 227
9.2.4 Client-Zertifikate 228
9.2.5 HMAC über HTTP 229
9.2.6 API-Schlüssel 230
9.2.7 Das Stellvertreterproblem 231
9.3 Schutz ruhender Daten 233
9.3.1 Wohlbekannte Verfahren einsetzen 234
9.3.2 Die Bedeutung der Schlüssel 235
9.3.3 Was soll verschlüsselt werden? 235
9.3.4 Entschlüsselung bei Bedarf 236
9.3.5 Backups verschlüsseln 236
9.4 Gestaffelte Sicherheitsstrategie 236
9.4.1 Firewalls 236
9.4.2 Protokollierung 236
9.4.3 Intrusion-Detection-Systeme 237
9.4.4 Unterteilung des Netzwerks 237
9.4.5 Betriebssystem 238
9.5 Ein ausgearbeitetes Beispiel 239
9.6 Datensparsamkeit 241
9.7 Der Faktor Mensch 242
9.8 Eine Goldene Regel 242
9.9 Integrierte Sicherheit 243
9.10 Externe Prüfung 243
9.11 Fazit 244
Kapitel 10: Conways Gesetz und Systemdesign 245
10.1 Beweise 245
10.1.1 Lose und eng gekoppelte Organisationen 246
10.1.2 Windows Vista 246
10.2 Netflix und Amazon 246
10.3 Was kann man damit anfangen? 247
10.4 Anpassung an Kommunikationswege 247
10.5 Verantwortlichkeit für Services 249
10.6 Gemeinschaftliche Verantwortlichkeit für Services 249
10.6.1 Schwierige Aufspaltung 249
10.6.2 Feature-Teams 250
10.6.3 Engpässe bei der Auslieferung 250
10.7 Interner Open-Source-Code 251
10.7.1 Aufgaben der Koordinatoren 252
10.7.2 Ausgereifte Services 253
10.7.3 Werkzeugsammlungen 253
10.8 Begrenzte Kontexte und Teamstrukturen 253
10.9 Verwaiste Services? 254
10.10 Fallstudie: RealEstate.com.au 254
10.11 Conways Gesetz auf den Kopf gestellt 256
10.12 Menschen 257
10.13 Fazit 258
Kapitel 11: Microservices skalieren 259
11.1 Ausfälle gibt es immer 259
11.2 Wie viel ist zu viel? 260
11.3 Schrittweiser Abbau der Funktionalität 261
11.4 Architektonische Sicherheitsmaßnahmen 262
11.5 Die antifragile Organisation 265
11.5.1 Timeouts 266
11.5.2 Circuit Breaker 266
11.5.3 Das Bulkhead-Pattern 269
11.5.4 Isolierung 270
11.6 Idempotenz 270
11.7 Skalierung 272
11.7.1 Mehr Leistung 272
11.7.2 Arbeitslast aufteilen 273
11.7.3 Risikoverteilung 273
11.7.4 Lastverteilung 274
11.7.5 Worker-Systeme 276
11.7.6 Neuanfang 277
11.8 Datenbanken skalieren 278
11.8.1 Verfügbarkeit des Services kontra Lebensdauer der Daten 278
11.8.2 Skalierung bei Lesevorgängen 279
11.8.3 Skalierung bei Schreibvorgängen 280
11.8.4 Gemeinsam genutzte Datenbankinfrastruktur 281
11.8.5 CQRS 281
11.9 Caching 282
11.9.1 Clientseitiges Caching, Proxy und serverseitiges Caching 283
11.9.2 Caching und HTTP 284
11.9.3 Caching bei Schreibvorgängen 285
11.9.4 Caching zur Erhöhung der Belastbarkeit 286
11.9.5 Den Ursprung verbergen 286
11.9.6 Möglichst einfach 287
11.9.7 Cache Poisoning: Ein warnendes Beispiel 288
11.10 Automatische Skalierung 289
11.11 Das CAP-Theorem 290
11.11.1 Aufgabe der Konsistenz 292
11.11.2 Aufgabe der Verfügbarkeit 292
11.11.3 Aufgabe der Partitionstoleranz? 294
11.11.4 AP oder CP? 294
11.11.5 Keine Frage eines Entweder-Oders 294
11.11.6 Abbildung der Wirklichkeit 295
11.12 Serviceerkennung 296
11.12.1 DNS 296
11.13 Dynamische Registrierung von Services 298
11.13.1 Zookeeper 298
11.13.2 Consul 300
11.13.3 Eureka 301
11.13.4 Eigene Serviceregistrierung 301
11.13.5 Menschliches Interesse 302
11.14 Services dokumentieren 302
11.14.1 Swagger 302
11.14.2 HAL und der HAL-Browser 303
11.15 Ein sich selbst beschreibendes System 304
11.16 Fazit 305
Kapitel 12: Auf den Punkt gebracht 307
12.1 Prinzipien 307
12.1.1 Geschäftsvorgänge modellieren 308
12.1.2 Automatisierung kultivieren 308
12.1.3 Implementierungsdetails verbergen 309
12.1.4 Dezentralisierung 309
12.1.5 Unabhängiges Deployment 310
12.1.6 Ausfälle eingrenzen 310
12.1.7 Umfassendes Monitoring 311
12.2 Wann sollte man auf Microservices verzichten? 311
12.3 Schlusswort 312
Stichwortverzeichnis 313
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...
| Erscheint lt. Verlag | 6.7.2015 |
|---|---|
| Sprache | deutsch |
| Themenwelt | Mathematik / Informatik ► Informatik ► Programmiersprachen / -werkzeuge |
| Schlagworte | Continuous Delivery • Deployment • Programmierung • SOA • Softwarearchitektur • Softwareentwicklung • Web-Apps • WebServices |
| ISBN-10 | 3-95845-082-2 / 3958450822 |
| ISBN-13 | 978-3-95845-082-0 / 9783958450820 |
| Haben Sie eine Frage zum Produkt? |
PDF (Ohne DRM)Größe: 4,4 MB
Digital Rights Management: ohne DRM
Dieses eBook enthält kein DRM oder Kopierschutz. Eine Weitergabe an Dritte ist jedoch rechtlich nicht zulässig, weil Sie beim Kauf nur die Rechte an der persönlichen Nutzung erwerben.
Dateiformat: PDF (Portable Document Format)
Mit einem festen Seitenlayout eignet sich die PDF besonders für Fachbücher mit Spalten, Tabellen und Abbildungen. Eine PDF kann auf fast allen Geräten angezeigt werden, ist aber für kleine Displays (Smartphone, eReader) nur eingeschränkt geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür einen PDF-Viewer - z.B. den Adobe Reader oder Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür einen PDF-Viewer - z.B. die kostenlose Adobe Digital Editions-App.
Zusätzliches Feature: Online Lesen
Dieses eBook können Sie zusätzlich zum Download auch online im Webbrowser lesen.
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
EPUB (Ohne DRM)Größe: 5,2 MB
Digital Rights Management: ohne DRM
Dieses eBook enthält kein DRM oder Kopierschutz. Eine Weitergabe an Dritte ist jedoch rechtlich nicht zulässig, weil Sie beim Kauf nur die Rechte an der persönlichen Nutzung erwerben.
Dateiformat: EPUB (Electronic Publication)
EPUB ist ein offener Standard für eBooks und eignet sich besonders zur Darstellung von Belletristik und Sachbüchern. Der Fließtext wird dynamisch an die Display- und Schriftgröße angepasst. Auch für mobile Lesegeräte ist EPUB daher gut geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür die kostenlose Software Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür eine kostenlose App.
Geräteliste und zusätzliche Hinweise
Zusätzliches Feature: Online Lesen
Dieses eBook können Sie zusätzlich zum Download auch online im Webbrowser lesen.
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
aus dem Bereich
