Cloud-native Architektur und Infrastrukturarchitektur

Willkommen zu Kapitel 10: Cloud-native Architektur und Infrastrukturarchitektur. Über den größten Teil der Geschichte der Software kam die Infrastruktur nach der Architektur: Ein Betriebsteam erhielt eine fertige Anwendung und suchte Server dafür. Diese Trennung gibt es nicht mehr. Heute entscheidet die Wahl zwischen virtuellen Maschinen, Containern, Plattformen und Funktionen über einen Großteil der Kosten. Die Zahl der Availability Zones und Regionen entscheidet über die Verfügbarkeit. Und die Deployment-Pipeline entscheidet, wie schnell und sicher ein Team etwas ändern kann.

Dieses Kapitel richtet sich an Entwicklungsteams und Architekten, die die Plattformen ihrer Systeme auswählen, begründen und betreiben wollen, ohne sich einen Stack verkaufen zu lassen. Es baut auf Kapitel 0 auf, das Server, virtuelle Maschinen, Container, Cloud-Servicemodelle, Regionen und Availability Zones eingeführt hat, und auf Kapitel 9, das erklärt hat, wie Systeme skalieren, kontrolliert degradieren und beobachtbar bleiben. Hier treffen diese Ideen auf die Plattformen, auf denen die meisten Systeme heute laufen. Entscheidungen darüber, wo und wie Software läuft, sind teuer rückgängig zu machen, betreffen alle Teams und legen die Qualitätsmerkmale fest, die Sie nach Kapitel 2 spezifizieren sollten. Und Kapitel 11 folgt mit der Frage, wie man eine Architektur einschließlich ihrer Infrastruktur beurteilt und sie im Lauf der Zeit sicher verändert.

Das durchgehende Beispiel ist die Essenslieferplattform aus dem ganzen Kurs: Kunden- und Restaurant-Apps, ein Bestellservice, Speisekarten, Zahlungen, Kurierdisposition und ein heftiger Ansturm am Abend. Die ersten vier Abschnitte behandeln die Grundlagen. Abschnitt zehn Punkt eins legt dar, wer was verwaltet, von Infrastructure as a Service, kurz IaaS, über PaaS und Funktionen bis zu SaaS. Im Modell der geteilten Verantwortung sind Ihre Daten, Identitäten und Konfiguration immer Ihre Aufgabe. Abschnitt zehn Punkt zwei erklärt Container-Images, Control Plane und Nodes von Kubernetes und den Reconciliation Loop in seinem Zentrum. Er sagt auch ehrlich, wann Kubernetes überdimensioniert ist. Abschnitt zehn Punkt drei geht alle zwölf Faktoren der Twelve-Factor App mit heutigen Einschränkungen durch und zeigt, wie man einen bestehenden Service daran prüft. Abschnitt zehn Punkt vier behandelt Infrastructure as Code: deklarative Werkzeuge, State und Drift, Module, Immutable Infrastructure, GitOps, Policy as Code und Tests.

Die wichtigste Idee dieses Kapitels ist ein deklarierter gewünschter Zustand, den Automatisierung fortlaufend abgleicht. Dieses Diagramm aus Abschnitt zehn Punkt zwei zeigt, wie Kubernetes das macht. Sie deklarieren den gewünschten Zustand. Hier: drei Replikas des Bestellservice in Version zwei Punkt vier. Ein Controller beobachtet den tatsächlichen Zustand des Clusters und findet nur zwei laufende Pods. Er vergleicht, was er sieht, mit dem Deklarierten und stellt fest, dass ein Pod fehlt. Also handelt er und fordert einen neuen Pod an. Die Schleife wiederholt sich bei jedem Änderungsereignis und in regelmäßigen Abständen. Weil er auf die aktuelle Differenz reagiert und nicht auf eine gemerkte Abfolge von Ereignissen, richten verpasste Ereignisse und Neustarts keinen bleibenden Schaden an. Dieselbe Idee zieht sich durch Infrastrukturcode, GitOps, Deployment-Pipelines und Immutable Infrastructure. Ein Mensch ändert eine Beschreibung, die geprüft, versioniert und nachvollziehbar ist, und Maschinen erledigen den Rest.

Die zweiten vier Abschnitte behandeln Veränderung, Skalierung, Menschen und Geld. Abschnitt zehn Punkt fünf verfolgt eine Änderung vom Commit bis in die Produktion durch eine CI/CD-Pipeline, vergleicht Rolling-, Blue-Green-, Canary- und Shadow-Deployments und trennt Deployment und Release mit Feature-Flags. Abschnitt zehn Punkt sechs vergleicht Disaster-Recovery-Strategien, erklärt, was die Replikation von Daten über Regionen für die Konsistenz bedeutet, und behandelt zellbasierte Architektur und Edge Functions. Abschnitt zehn Punkt sieben behandelt die Internal Developer Platform als Produkt mit Golden Paths und Guardrails und zeigt, wie man misst, ob sie hilft. Und Abschnitt zehn Punkt acht macht Kosten zu einer Architekturqualität, gemessen pro Bestellung, und behandelt Anbieter-Lock-in als Abwägung, die zu bepreisen ist, statt als Sünde, die es zu vermeiden gilt.

Die zweite Idee lautet, dass jede Option in diesem Kapitel eine Abwägung ist. Dieses Diagramm aus Abschnitt zehn Punkt sechs zeigt vier Disaster-Recovery-Strategien nebeneinander. Jede wird an zwei Zahlen gemessen, die vom Fachbereich kommen: dem Recovery Time Objective, kurz RTO, also wie lange Sie ausfallen dürfen, und dem Recovery Point Objective, kurz RPO, also wie viele Daten Sie verlieren dürfen. Bei Backup und Wiederherstellung werden Backups in eine Wiederherstellungsregion kopiert, in der nichts läuft. Die Wiederherstellung dauert Stunden, und Sie verlieren alles seit dem letzten Backup. Bei Pilot Light werden die Daten repliziert, aber die Anwendungsserver sind aus. Bei Warm Standby läuft bereits eine kleine funktionsfähige Kopie, die hochskaliert wird. Die Wiederherstellungszeit sinkt auf einige zehn Minuten, dann auf Minuten. Bei Active-Active bedient eine vollständige zweite Region bereits Datenverkehr, und beide Zahlen liegen nahe null. Jeder Schritt nach rechts erkauft schnellere Wiederherstellung und weniger Datenverlust zu höheren laufenden Kosten und mehr Komplexität. Die richtige Wahl hängt von der Arbeitslast und der Organisation ab.

Am Ende des Kapitels können Sie die Cloud-Service- und Bereitstellungsmodelle vergleichen und die Aufgaben für eine Arbeitslast nach dem Modell der geteilten Verantwortung zuordnen. Sie verstehen, wie Kubernetes einen deklarierten gewünschten Zustand aufrechterhält, und können beurteilen, wann es überdimensioniert ist. Sie können zwischen Rolling-, Blue-Green-, Canary- und Shadow-Deployments wählen und Feature-Flags nutzen, um Deployment und Release zu trennen. Und Sie können Stückkosten wie die Kosten pro Bestellung berechnen und Lock-in als bepreiste Abwägung bewerten.

Jeder Abschnitt lässt sich für sich lesen, aber die Reihenfolge ist bewusst gewählt. Über Deployment-Strategien kann man nicht nachdenken, ohne zu wissen, was Kubernetes während eines Rollouts tut. Wenn Sie neu im Betrieb sind, lesen Sie zuerst die Kästen für Einsteiger und den Abschnitt über Server und die Cloud in Kapitel 0. Machen Sie sich keine Sorgen, Werkzeugnamen auswendig zu lernen. Produkte ändern sich alle paar Jahre, die Mechanismen bleiben. Anbieter werden als Beispiele genannt, nicht als Empfehlungen. Am Ende jedes Abschnitts stehen Fragen zur Selbstkontrolle. Beantworten Sie sie im Kopf, bevor Sie sich die Antworten ansehen. Planen Sie etwa drei Stunden ein, um das ganze Kapitel zu lesen. Wenn Sie so weit sind, gibt es einen optionalen Kapiteltest von etwa fünfundvierzig Minuten mit zwanzig Multiple-Choice-Fragen und zwei schriftlichen Antworten. Die Bestehensgrenze liegt bei achtzig Prozent.

So ist das Kapitel aufgebaut. Beginnen Sie mit Abschnitt zehn Punkt eins über Cloud-Service- und Bereitstellungsmodelle und darüber, wer wofür verantwortlich ist. Bis gleich.