Kratzke Cloud-native Computing
2. aktualisierte Auflage 2023
ISBN: 978-3-446-47925-8
Verlag: Carl Hanser
Format: PDF
Kopierschutz: 1 - PDF Watermark
Software Engineering von Diensten und Applikationen für die Cloud
E-Book, Deutsch, 394 Seiten
ISBN: 978-3-446-47925-8
Verlag: Carl Hanser
Format: PDF
Kopierschutz: 1 - PDF Watermark
- Grundlagen des Cloud Computings (Service-Modelle und Cloud-Ökonomie)
- Das Everything-as-Code-Paradigma (DevOps, Deployment Pipelines, IaC)
- Den Systembetrieb mit Container-Orchestrierung automatisieren
- Microservice- und Serverless-Architekturen verstehen und Cloud-native-Architekturen mit Domain Driven Design entwerfen
- Ihr exklusiver Vorteil: E-Book inside beim Kauf des gedruckten Buches
Märkte verändern sich immer schneller, Kundenwünsche stehen im Mittelpunkt – viele Unternehmen sehen sich Herausforderungen gegenüber, die nur digital beherrschbar sind. Um diese Anforderungen zu bewältigen, bietet sich der Einsatz von Cloud-native-Technologien an. Dabei reicht es jedoch nicht aus, einen Account bei einem Cloud-Anbieter anzulegen. Es geht auch darum, die unterschiedlichen Faktoren zu verstehen, die den Erfolg von Cloud-native-Projekten beeinflussen.
Das Buch beleuchtet den Cloud-native-Wandel aus unterschiedlichen Perspektiven: von der Unternehmenskultur, der Cloud-Ökonomie und der Einbeziehung der Kunden (Co-Creation) über das Projektmanagement (Agilität) und die Softwarearchitektur bis hin zu Qualitätssicherung (Continuous Delivery), Betrieb (DevOps) und Sicherheit. Anhand von realen Praxisbeispielen wird gezeigt, was bei der Umsetzung in unterschiedlichen Branchen gut und was schlecht gelaufen ist und welche Best Practices sich daraus ableiten lassen. Dabei wird auch die Migration von Legacy-Code berücksichtigt.
IT-Architekten vermittelt dieses Buch zudem das grundlegende Wissen, um Cloud-native-Technologien und die DevOps-Kultur in ihrem Projekt oder im gesamten Unternehmen einzuführen.
Autoren/Hrsg.
Fachgebiete
Weitere Infos & Material
1;Inhalt;7
2;Vorwort;15
3;1Einleitung;17
3.1;1.1?An wen sich dieses Buch richtet;18
3.2;1.2?Was dieses Buch behandelt;19
3.3;1.3?Sprachliche Konventionen;21
3.4;1.4?Notationskonventionen;22
3.5;1.5?Ergänzende Materialien;23
4;Teil?I: Grundlagen;25
5;2Cloud Computing;27
5.1;2.1?Service-Modelle;28
5.1.1;2.1.1?Infrastructure as a Service (IaaS);31
5.1.2;2.1.2?Platform as a Service (PaaS);31
5.1.3;2.1.3?Software as a Service (SaaS);32
5.2;2.2?Cloud-Ökonomie;35
5.2.1;2.2.1?Eignung von unterschiedlichen Arten von Workloads;35
5.2.2;2.2.2?Effekt von Zuteilungsdauer und Ressourcengröße;38
5.3;2.3?Entwicklung der letzten Jahre;40
6;3DevOps;43
6.1;3.1?Prinzipien des Flow;45
6.1.1;3.1.1?Prinzip?1: Arbeit sichtbar machen;45
6.1.2;3.1.2?Prinzip?2: Work in Progress beschränken;46
6.1.3;3.1.3?Prinzip?3: Flaschenhälse minimieren;47
6.2;3.2?Prinzipien des Feedbacks;48
6.2.1;3.2.1?Prinzip?4: Probleme früh erkennen;48
6.2.2;3.2.2?Prinzip?5: Probleme sofort lösen;48
6.2.3;3.2.3?Prinzip?6: Probleme professionell verantworten;49
6.3;3.3?DevOps-geeignete Architekturen;49
6.3.1;3.3.1?Randbedingungen für die Entwicklung;50
6.3.2;3.3.2?Nutzung von Orchestrierungsplattformen;50
6.3.3;3.3.3?Randbedingungen im Betrieb;51
7;4Cloud-native;53
7.1;4.1?Definitionen in Industrie und Forschung;55
7.2;4.2?Die Cloud-native-Definition dieses Buchs;56
7.3;4.3?Zusammenfassung und Ausblick?auf?Teil?II bis IV;57
8;Teil?II: Everything?as?Code;61
9;5Einleitung zu Teil?II;63
10;6Deployment-Pipelines;65
10.1;6.1?Deployment-Pipelines as Code;66
10.1.1;6.1.1?Phasen-Pipelines;67
10.1.2;6.1.2?Gerichtete Pipelines;68
10.1.3;6.1.3?Hierarchische Pipelines;69
10.1.4;6.1.4?Steuerung von Pipelines;70
10.2;6.2?DevOps-geeignete Branching-Strategien;72
10.2.1;6.2.1?Git-Flow;73
10.2.2;6.2.2?GitHub-Flow;74
10.2.3;6.2.3?Trunk-basierte Entwicklung;75
10.3;6.3?Zusammenfassung;76
11;7Infrastructure as?Code;79
11.1;7.1?Virtualisierung;81
11.1.1;7.1.1?Virtualisierung von Hardware-Infrastruktur;81
11.1.2;7.1.2?Virtualisierung von Software-Infrastruktur;82
11.2;7.2?Provisionierung;84
11.2.1;7.2.1?Immutable Infrastructure;84
11.2.2;7.2.2?IaC-Ansätze;85
11.2.3;7.2.3?Provisionierung von lokalen Umgebungen;88
11.2.4;7.2.4?Provisionierung von Multi-Host-Umgebungen;90
11.3;7.3?Zusammenfassung;93
12;8Standardisierung von Deployment Units (Container);95
12.1;8.1?Hintergrund (PaaS);95
12.2;8.2?Betriebssystem-Virtualisierung;98
12.3;8.3?Container Runtime Environments;99
12.3.1;8.3.1?Kernel-Namespaces;100
12.3.2;8.3.2?Process Capabilities;101
12.3.3;8.3.3?Control Groups;102
12.3.4;8.3.4?Union Filesystem;102
12.3.5;8.3.5?High-Level- und Low-Level-Container-Laufzeitumgebungen;103
12.4;8.4?Bau und Bereitstellung von?Container?Images;104
12.5;8.5?Faktoren gut betreibbarer Container;106
12.5.1;8.5.1?Codebase;107
12.5.2;8.5.2?Abhängigkeiten und Konfigurationen;107
12.5.3;8.5.3?Unterstützende Services und Port Binding;108
12.5.4;8.5.4?Build-, Release- und Run-Phase;109
12.5.5;8.5.5?Horizontale Skalierung über Prozesse;110
12.5.6;8.5.6?Umgebungen, Logs und Betrieb;111
12.6;8.6?Zusammenfassung;112
13;9Container-Plattformen;115
13.1;9.1?Scheduling;116
13.1.1;9.1.1?Heterogenität von Workloads;117
13.1.2;9.1.2?Scheduling-Algorithmen;118
13.1.2.1;9.1.2.1?Einfache Scheduling-Algorithmen;118
13.1.2.2;9.1.2.2?Multidimensionale Scheduling-Algorithmen;119
13.1.2.3;9.1.2.3 Kapazitätsbasierte Scheduling-Algorithmen;119
13.1.3;9.1.3?Scheduling-Architekturen;120
13.1.3.1;9.1.3.1?Monolithischer Scheduler;121
13.1.3.2;9.1.3.2?2-Level-Scheduler;121
13.1.3.3;9.1.3.3?Shared-State Scheduler;122
13.2;9.2?Orchestrierung;123
13.2.1;9.2.1?Definition von Betriebszuständen;123
13.2.2;9.2.2?Regelkreis: Desired versus Current State;124
13.3;9.3?Inside Kubernetes;125
13.3.1;9.3.1?Kubernetes-Architektur;126
13.3.2;9.3.2?Verwaltete Ressourcen und Basis-Blueprint;128
13.3.3;9.3.3?Schedulbare Workloads;130
13.3.3.1;9.3.3.1?Deployments;130
13.3.3.2;9.3.3.2?(Cron-)Jobs;132
13.3.3.3;9.3.3.3?Daemon-Sets;133
13.3.3.4;9.3.3.4?Stateful-Sets;134
13.3.4;9.3.4?Scheduling Constraints;137
13.3.4.1;9.3.4.1?Angabe des Ressourcenbedarfs mittels Requests und Limits;137
13.3.4.2;9.3.4.2?Knoten-Selektoren;138
13.3.4.3;9.3.4.3?Knotenaffinitäten;139
13.3.4.4;9.3.4.4?Pod-(Anti-)Affinitäten;140
13.3.5;9.3.5?Automatische Skalierung von Workloads;141
13.3.6;9.3.6?Exponieren von Workloads als interne und externe Services;142
13.3.7;9.3.7?Health Checking;145
13.3.8;9.3.8?Persistenz;148
13.3.9;9.3.9?Isolation von Workloads;149
13.3.9.1;9.3.9.1?Namespaces und Role-based Access Model (Multi-Tenancy);149
13.3.9.2;9.3.9.2?Quotas und Limit Ranges;150
13.3.9.3;9.3.9.3?Network Policys;151
13.4;9.4?Zusammenfassung;153
14;10Function as a Service;157
14.1;10.1?FaaS-Plattformen;159
14.1.1;10.1.1?Das FaaS-Programmiermodell;161
14.1.2;10.1.2?Zu berücksichtigende Randbedingungen;162
14.1.3;10.1.3?Veranschaulichung des FaaS-Programmiermodells;163
14.2;10.2?Plattformagnostische FaaS?Frameworks;165
14.3;10.3?Ereignisbasierte Autoskalierung;168
14.4;10.4?Zusammenfassung;171
15;Teil?III: Cloud-native Architekturen;173
16;11Einleitung zu Teil?III;175
17;12Microservice und Serverless-Architekturen;177
17.1;12.1?Eigenschaften von Microservices;178
17.2;12.2?Integrationsmuster für Microservices;182
17.2.1;12.2.1?Datenbankbasierte Integration;183
17.2.2;12.2.2?(g)RPC-basierte Interprozesskommunikation;183
17.2.3;12.2.3?Representational State Transfer (REST);186
17.2.4;12.2.4?Ereignisbasierte Integration (asynchron);189
17.2.5;12.2.5?API-Versioning;191
17.3;12.3?Architekturelle Sicherheit;194
17.3.1;12.3.1?Circuit-Breaker;194
17.3.2;12.3.2?Bulkhead;195
17.3.3;12.3.3?Idempotente API-Operationen;196
17.4;12.4?Skalierung von Microservices;196
17.4.1;12.4.1?Load Balancing;197
17.4.2;12.4.2?Messaging;197
17.4.3;12.4.3?Skalierung zustandsbehafteter Komponenten;199
17.4.3.1;12.4.3.1?Scaling for Reads;200
17.4.3.2;12.4.3.2?Scaling for Writes (Sharding);200
17.4.3.3;12.4.3.3?Command Query Responsibility Segregation (CQRS);201
17.4.4;12.4.4?Caching;202
17.5;12.5?Prinzipien zur Entwicklung von?Microservices;203
17.5.1;12.5.1?Prinzip?1: Bilde Modelle um Geschäftskonzepte;203
17.5.2;12.5.2?Prinzip?2: Erschaffe eine Kultur der Automatisierung;203
17.5.3;12.5.3?Prinzip?3: Blende interne Implementierungsdetails aus;204
17.5.4;12.5.4?Prinzip?4: Dezentralisiere;204
17.5.5;12.5.5?Prinzip?5: Definiere unabhängig aktualisierbare Einheiten;204
17.5.6;12.5.6?Prinzip?6: Isoliere Fehler;205
17.5.7;12.5.7?Prinzip?7: Baue gut beobachtbare Services;205
17.6;12.6?Serverless-Architekturen;206
17.6.1;12.6.1?Architekturelle Konsequenzen von Serverless-Limitierungen;207
17.6.2;12.6.2?Das API-Gateway-Pattern;209
17.6.3;12.6.3?Abgrenzung zu Microservices;211
17.7;12.7?Zusammenfassung;212
18;13Beobachtbare Architekturen;215
18.1;13.1?Konsolidierung von Telemetriedaten;216
18.2;13.2?Instrumentierung von Systemen;218
18.2.1;13.2.1?Logging;218
18.2.2;13.2.2?Monitoring;220
18.2.2.1;13.2.2.1?Metrikarten;222
18.2.2.2;13.2.2.2?Empfehlungen für die Metrikinstrumentierung;223
18.2.3;13.2.3?Tracing;223
18.2.3.1;13.2.3.1?Empfehlungen für die Instrumentierung;225
18.2.3.2;13.2.3.2?Tracing-Instrumentierung und Erzeugung von Spans;228
18.2.3.3;13.2.3.3?Serverseitiges Tracing und Extraktion von Span-Kontexten;229
18.2.3.4;13.2.3.4?Clientseitiges Tracing und Weiterreichen von Span-Kontexten;230
18.3;13.3?Automatisierte Instrumentierung;231
18.3.1;13.3.1?Eigenschaften von Service-Meshs;232
18.3.2;13.3.2?Traffic-Management;234
18.3.3;13.3.3?Resilienz;237
18.3.4;13.3.4?Sicherheit;239
18.3.5;13.3.5?Management und Analyse von Verkehrstopologien;242
18.4;13.4?Zusammenfassung;243
19;14Domain-driven Design;245
19.1;14.1?Fachlichkeit;246
19.2;14.2?Strategisches Design;248
19.2.1;14.2.1?Subdomänen;249
19.2.1.1;14.2.1.1?Kerndomäne (Core Subdomain);249
19.2.1.2;14.2.1.2?Unterstützende Subdomäne (Supporting Subdomain);250
19.2.1.3;14.2.1.3?Generische Subdomänen (Generic Subdomain);250
19.2.1.4;14.2.1.4?Anmerkungen am Beispiel einer Fallstudie;250
19.2.2;14.2.2?Ubiquitous Language;252
19.2.2.1;14.2.2.1?Eine gemeinsame Sprache als Schlüssel zu einem gemeinsamen Verständnis;253
19.2.2.2;14.2.2.2?Mehrdeutige und synonyme Begriffe;254
19.2.3;14.2.3?Bounded Contexts;255
19.2.4;14.2.4?Context Mapping;257
19.2.4.1;14.2.4.1?Partnerschaftliche Kooperationsmuster (Partners?und?Shared?Kernel);257
19.2.4.2;14.2.4.2?Customer-Supplier-Kooperation;259
19.2.4.3;14.2.4.3?Separate Ways;260
19.2.4.4;14.2.4.4?Context Maps als Landkarte von Machtverhältnissen;261
19.3;14.3?Taktisches Design;262
19.3.1;14.3.1?Oft genutzte Pattern für Geschäftslogik;262
19.3.1.1;14.3.1.1?Das ETL-Pattern (primär Supporting Subdomains);262
19.3.1.2;14.3.1.2?Das Active Record-Pattern (primär Supporting Subdomains);263
19.3.1.3;14.3.1.3?Das Domain Model-Pattern (primär Core Subdomains);264
19.3.1.4;14.3.1.4?Das Event-Sourcing-Pattern (primär Core Subdomains);266
19.3.2;14.3.2?Oft genutzte Pattern für die Architektur;267
19.3.2.1;14.3.2.1?Die Ebenen-Architektur;268
19.3.2.2;14.3.2.2?Das Ports & Adapter-Pattern;269
19.3.2.3;14.3.2.3?Das CQRS-Pattern;269
19.4;14.4?Zusammenfassung;272
20;Teil?IV: Sichere?Cloud-native Anwendungen;275
21;15Einleitung zu Teil?IV;277
22;16Härtung Cloud-nativer Anwendungen;279
22.1;16.1?Härtung (virtueller) Infrastrukturen;283
22.1.1;16.1.1?Tool-gestütztes System Hardening;284
22.1.2;16.1.2?Kontinuierliche Aktualisierung von virtuellen Maschinen;286
22.1.3;16.1.3?Sichere Authentifizierung mittels SSH;287
22.1.4;16.1.4?Kontinuierliche Überwachung virtueller Maschinen;289
22.1.4.1;16.1.4.1?Verhaltensbasierte Intrusion Detection mittels Auditing;289
22.1.4.2;16.1.4.2?Signaturbasierte Intrusion Detection;290
22.1.4.3;16.1.4.3?Log Forwarding;292
22.1.5;16.1.5?Einsatz von Sicherheitsgruppen und Firewalls;293
22.2;16.2?Härtung containerisierter Workloads;295
22.2.1;16.2.1?Absicherung von Public Endpoints mittels Ingresses;296
22.2.2;16.2.2?Namespace-basierte Netzwerkisolation;302
22.2.3;16.2.3?Pod Hardening;305
22.2.4;16.2.4?Erhöhung der Container Runtime Isolation;315
22.2.5;16.2.5?Volume Hardening;316
22.2.6;16.2.6?Workload Policing;319
22.2.7;16.2.7?Intrusion Detection;323
22.2.8;16.2.8?Sicherung der Supply Chain;326
22.2.8.1;16.2.8.1?Statische Software Composition Analysis (SCA);327
22.2.8.2;16.2.8.2?Static Application Security Testing (SAST);330
22.2.8.3;16.2.8.3?Kontinuierliches Schwachstellen-Scanning von Container-Plattformen;332
22.3;16.3?Zusammenfassung;335
23;17Regulatorische Anforderungen;337
23.1;17.1?Cloud Compliance und Zertifizierungen;338
23.1.1;17.1.1?ISO?9001;340
23.1.2;17.1.2?BSI-IT-Grundschutz und BSI-Standards;341
23.1.3;17.1.3?BSI-C5-Zertifizierung;341
23.1.4;17.1.4?ISO/IEC?27001 und 27017/27018;342
23.1.5;17.1.5?CSA STAR;343
23.1.6;17.1.6?CISPE Code of Conduct;344
23.1.7;17.1.7?EU Cloud Code of Conduct;345
23.1.8;17.1.8?SOC?1-3 (Service Organization Control);346
23.1.9;17.1.9?FedR347
23.1.10;17.1.10?HIPAA;347
23.1.11;17.1.11?PCI DSS;348
23.1.12;17.1.12?Zusammenfassung;349
23.2;17.2?Aus der DSGVO sich ergebende Anforderungen;351
23.2.1;17.2.1?Personenbezogene Daten;351
23.2.2;17.2.2?Grundsätze der Verarbeitung personenbezogener Daten;352
23.2.3;17.2.3?Auftragsverarbeitung;354
23.2.4;17.2.4?Datenschutz-Folgenabschätzungen;356
23.2.5;17.2.5?Internationale Datentransfers in Drittländer;357
23.3;17.3?Europäischer Datenschutz und?Drittländer;359
23.3.1;17.3.1?Probleme am Beispiel des CLOUD Act;360
23.3.2;17.3.2?Lösungen trotz SCHREMS?I?+?II;361
23.4;17.4?Zusammenfassung;362
24;18Schlussbemerkungen;365
25;Literaturverzeichnis;375
26;Stichwortverzeichnis;381
1 Einleitung In Zeiten des digitalen Wandels ist Cloud Computing heute mehr und mehr die primäre Option und nicht mehr nur eine von vielen technischen Möglichkeiten. Insbesondere Start-ups wählen kaum noch den Weg über den Aufbau „klassischer“ On-Premise-Lösungen (Rechenzentren). Insbesondere in frühen Phasen eines Unternehmens wird der Aufbau eigener Serverkapazitäten als zu kapital- und personalintensiv empfunden. Der weltweite Markt für Public Cloud Services wächst folgerichtig Jahr um Jahr; 2019 beispielsweise um etwa 17 Prozent auf insgesamt mehr als 214 Milliarden Dollar. Das am schnellsten wachsende Marktsegment sind hierbei Infrastruktur-Dienste (IaaS) und Plattform-Dienste (PaaS). 70 % dieses Marktes teilen sich dabei die „sogenannten“ Big Five. Dies waren 2020 Amazon, Microsoft, Alibaba, Google und IBM, also alles nichteuropäische Anbieter. Diese sogenannten Hyperscaler unterliegen rechtlichen Regularien ihrer Heimatländer. Amazon, Microsoft und Google unterliegen beispielsweise dem US CLOUD Act. Der CLOUD Act verpflichtet Provider, US-Behörden Zugriff auf gespeicherte Daten zu gewähren, auch wenn die Speicherung nicht in den USA erfolgt. Alibaba unterliegt den Regularien der Volksrepublik China mit vergleichbaren staatlichen Regularien. Solche Regularien decken sich nicht notwendig mit europäischen oder nationalen Datenschutz-Auffassungen und -Interessen. Auf europäische Initiative versucht man daher seit 2020, mit GAIA-X eine wettbewerbsfähige, sichere und vertrauenswürdige Dateninfrastruktur der „nächsten Generation“ für Europa aufzubauen, die eine „Datensouveränität“ gewährleisten soll. Dabei sollen insbesondere branchenübergreifende Kooperationen unterstützt werden, um faire und transparente Geschäftsmodelle zu fördern. Flankiert wird dies durch Regeln und Standards für kooperative und rechtskonforme Nutzung von Daten. Solche gemeinsamen Modelle und Regeln sollen die Komplexität und die Kosten der Kommerzialisierung von Daten reduzieren und deren Rechtskonformität erhöhen. Der europäische Ansatz ist also – im Vergleich zum aktuell von wenigen großen US-Hyperscalern dominierten Cloud-Computing-Markt – ein deutlich dezentralerer und kooperativerer Ansatz. Ob dieser Ansatz zu einer umfangreicheren Standardisierung und besseren Interoperabilität von Cloud-Diensten führt, muss die Zukunft allerdings erst noch zeigen. Es wird schwierig werden, in einer sehr agilen, bottom-up geprägten und lösungsorientierten Industrie durchaus fehlende und berechtigte Top-down-Standardisierungs-, Interoperabilitäts- und Datenschutzstrategien zu verankern. Man kann daher dem Cloud-Computing-Hype durchaus kritisch gegenüberstehen und sich Fragen stellen; zum Beispiel: Ist der GAIA-X Ansatz erfolgversprechend? Wie kritisch ist die Dominanz von US-Hyperscalern? Sollte man die Datenverarbeitung Firmen anvertrauen, die Regularien von nicht demokratisch geprägten Staaten wie der Volksrepublik China unterworfen sind? Solche und ähnliche Fragen sind durchaus berechtigt. Cloud Computing bleibt aber dennoch heute für viele Unternehmen, Organisationen, Behörden und Forschungseinrichtungen aus rein pragmatischen Gründen die primäre Option, digitalisierte Lösungen (schnell) realisieren zu können. Die Pandora ist nun einmal aus der Büchse. Cloud Computing wird nicht einfach wieder verschwinden. Die Corona-Krise hat dies noch einmal eindrucksvoll gezeigt. Cloud-basierte Lösungen waren in vielen Bereichen die „Strohhalme“, mit denen ganze Volkswirtschaften im Lockdown irgendwie den Kopf über Wasser halten konnten (Kratzke 2020). Man stelle sich nur einmal vor, was passiert wäre, wenn die Corona-Krise 30 Jahre vorher ausgebrochen wäre! Wie hätten wir uns dann im Homeoffice organisiert? Wäre Homeoffice überhaupt möglich gewesen? Es hätte definitiv keine hochskalierbaren Videokonferenzlösungen von Anbietern wie Zoom, Azure Teams oder Google Meet gegeben, die weltweit in kürzester Zeit mit unglaublichen Rechenressourcen hinterlegt werden konnten. Dieses „Primäre“ hat mittlerweile sogar einen Namen bekommen. Man nennt es „Cloud-native“ (Kratzke und Quint 2017; Kratzke 2018). Als Cloud-native Systeme werden in diesem Buch verteilte Systeme bezeichnet, die bewusst für Cloud-Infrastrukturen und Cloud-Plattformen entwickelt werden und nur effektiv in diesen betreibbar sind. Da diese Systeme primär variable Kosten durch ihren Ressourcenverbrauch generieren (Pay-as-you-go-Kostenmodell, siehe auch Abschnitt 2.3), haben sich Designmuster entwickelt, wie solche Systeme möglichst kostengünstig (d. h. ressourcenschonend) betrieben werden können. Dies hat massiven Einfluss auf die verwendeten Technologien, aber auch auf Architekturen genommen, mit denen solche Cloud-nativen Systeme entwickelt und betrieben werden. Um diese Hintergründe und Mechanismen Cloud-nativer Systeme soll es in diesem Buch gehen. 1.1 An wen sich dieses Buch richtet Dieses Buch richtet sich insbesondere an Studierende in Informatik- oder verwandten (Master-)Studiengängen. Gleichermaßen adressiert es Dozenten, die derartige Themen im Hochschul- oder beruflichen Weiterbildungskontext vermitteln. Insbesondere die ergänzenden Online-Materialien sind für diese Zielgruppe von Interesse. Aber auch Autodidakten oder IT-Seiteneinsteiger, die im IT-Umfeld Funktionen im weiteren Bereich der Softwareentwicklung innehaben oder diese anstreben, werden adressiert. Vor dem Hintergrund dieser Zielgruppen werden Themen des Cloud-native Computings mit dem Ziel, einen soliden und kritisch einordnenden Überblick zu geben, überwiegend auf Einsteigerniveau behandelt. Allerdings werden fundiertes softwaretechnisches Basiswissen und Programmierkenntnisse in mindestens einer prozeduralen oder objektorientierten Programmiersprache vorausgesetzt. Idealerweise ist es Python, aber andere Programmiersprachen sind auch gut anzuwenden. Ferner sind Erfahrungen mit unixoiden Betriebssystemen wie beispielsweise Linux von Vorteil. Dieses Buch richtet sich auch an technische Projektleiter, Berater, Softwarearchitekten und -entwickler, die Cloud-native Technologien und korrespondierende DevOps-Praktiken in Projekten oder Abteilungen einführen wollen oder damit erste Erfahrungen sammeln. Teil I ist auch für (bzw. die Kommunikation mit) C-Level-Funktionen (z. B. CIO, CTO) in Unternehmen geschrieben worden und kann Softwareentwicklern Argumente liefern, um Cloud-basierte Entwicklungsansätze kritisch, konstruktiv und lösungsorientiert mit Unternehmensleitungen zu diskutieren. 1.2 Was dieses Buch behandelt Das Buch ist in drei Teile gegliedert, die sich mit unterschiedlichen Bereichen des Cloudnative Computings befassen. Dies erstreckt sich von den theoretischen und konzeptionellen Grundlagen des Cloud Computings über praktisches „Hands-on“-Wissen der Basistechnologien bis hin zu architekturellen Überlegungen und dem verlässlichen Betrieb großer und komplexer Cloud-nativer Systeme. In Teil I werden primär die theoretischen und konzeptionellen Grundlagen des Cloud Computings behandelt. Kapitel 2 geht auf die bekannten Service-Modelle IaaS, PaaS und SaaS ein, die sich seit mehr als einer Dekade als eine feste konzeptionelle Gliederung im Cloud Computing bewährt haben. Behandelt wird ferner die „Cloud-Ökonomie“ und deren Einfluss auf den Technologiestack und Architekturen von Cloud-nativen Systemen, die wir heutzutage vorfinden. Kapitel 3 geht auf DevOps als eine treibende Philosophie des Cloud Computings ein. Insbesondere die DevOps-Prinzipien des Flow motivieren dabei den Teil II (Everything as Code) dieses Buches. Die DevOps-Prinzipien des Feedbacks legen die Grundlage für den Teil III (Observable Architectures). Das Kapitel 3 kann also durchaus als gedankliche Klammer gesehen werden. Das Kapitel 4 geht auf den Begriff Cloud-native an sich ein, um diesen Begriff präzise zu fassen und als Leitmotiv für dieses Buch aufzugreifen. Dieses Kapitel bildet damit den Einstieg in Teil II. Teil II betrachtet das „Handwerk“ der Cloud-nativen Programmierung. Die Basisfähigkeiten des Everything as Code bilden die Grundlage für Cloud-native Systementwicklung größerer Systeme. Das Buch überträgt hier das bewährte Vorgehen der Informatikausbildung vom Programming-in-the-Small zum Programming-in-the-Large auf Cloud-native Systeme. In der Informatikausbildung werden üblicherweise erst die Basisfertigkeiten des Programmierens im Kleinen vermittelt und erst anschließend die Fertigkeiten und...
