Cloud-native Architekturen und Plattformen

Cloud-native Architekturen und Plattformen

0:00 In diesem Modul geht es darum, worauf Ihre Architektur tatsächlich läuft — und was der Betrieb davon kostet. Ich beginne mit einer Beobachtung: Die Frage „Nehmen wir Kubernetes?" wird in Projekten früher gestellt als fast jede andere, und sie ist in Wirklichkeit eine der letzten, die beantwortet werden sollte. Denn sie hängt an Dingen, die vorher feststehen müssen: Wie viel Kontrolle brauchen Sie, wie viel Betrieb können Sie tragen, und was ist Ihr System wert, wenn niemand mehr Bereitschaft hat?

Cloud-native Architekturen und Plattformen

0:27 Fünf Kapitel. Zuerst die Bereitstellungsmodelle von IaaS bis FaaS, dann die konkrete Compute-Entscheidung entlang von Kriterien. Danach der Betrieb selbst: deklarative Umgebungen, sichere Auslieferung, Konfiguration und Geheimnisse. Viertens Platform Engineering — eine Entwicklung, die in den letzten Jahren viel Aufmerksamkeit bekommen hat und häufig missverstanden wird.

0:49 Und zum Schluss die Wirtschaftlichkeit, denn in der Cloud sind Kosten eine Architektureigenschaft.

Bereitstellungsmodelle

0:56 Beginnen wir mit der Landkarte. Die Abkürzungen kennen Sie vermutlich alle — was sich lohnt, ist der Blick auf die eine Achse, an der sie sich tatsächlich unterscheiden. Der einzige Unterschied, der zählt, ist die Verteilung der Verantwortung. Infrastructure as a Service stellt Ihnen Maschinen, Netz und Speicher hin — alles darüber gehört Ihnen, inklusive Betriebssystempflege und Sicherheitsaktualisierung.

1:20 Platform as a Service stellt eine verwaltete Laufzeit. Functions as a Service nimmt nur noch Code entgegen. Ein Bild dafür: Sie mieten ein leeres Grundstück, eine ausgestattete Küche oder buchen einen Caterer. Alle drei bringen Essen auf den Tisch, aber Sie tun jeweils etwas anderes dafür. Die Schichtung zeigt einen stetigen Übergang, keine getrennten Welten. Beachten Sie die Stufe dazwischen, die in vielen Darstellungen fehlt: Containers as a Service.

1:47 Ihre Container laufen, die Orchestrierung ist teilweise verwaltet, aber Sie betreiben keine Steuerebene. Genau diese Stufe ist für viele Teams die passende und wird übersprungen, weil die Diskussion direkt von virtuellen Maschinen zu Kubernetes springt. Die Frage ist immer dieselbe: Wie viel von dieser Verantwortung brauchen Sie wirklich?

2:07 Diese vier Punkte beschreiben ein Tauschgeschäft, das sich nicht umgehen lässt. Mehr Kontrolle bedeutet mehr Arbeit — und zwar dauerhaft, nicht einmalig. Weniger Arbeit bedeutet weniger Kontrolle, insbesondere über Laufzeitverhalten, Startzeiten und Grenzen. Wichtig ist, dass das kein Qualitätsgefälle ist. Es gibt gute Gründe, ganz links zu stehen, und gute Gründe für ganz rechts. Was es nicht gibt, ist beides gleichzeitig — und genau das wird in Projekten regelmäßig erwartet.

2:38 Die rechte Spalte nennt bewusst Gründe und keine Eigenschaften. Private Cloud wegen Datenschutz, Regulierung oder bereits getätigten Investitionen — das sind legitime Gründe, auch wenn sie in Cloud-Vorträgen selten vorkommen. Und dann Multi-Cloud: Verhandlungsposition, Ausfallszenarien, Kundenauflagen. Die Fußzeile nennt den Preis, und der ist hoch: doppelte Werkzeugketten, doppeltes Bereitschaftswissen. Multi-Cloud ist keine Versicherung, die man nebenbei abschließt.

3:07 Es ist eine Architekturentscheidung, die jede folgende verteuert. Der zweite Punkt ist die Realität hinter vielen Multi-Cloud-Beschlüssen: Sie werden gefasst, und danach nutzt man doch nur einen Anbieter — hat aber alle Abstraktionsschichten gebaut, die Portabilität ermöglichen sollten. Der dritte beschreibt, wie Hybrid meistens entsteht: nicht als Entwurf, sondern als liegengebliebener Zwischenstand einer Migration.

3:31 Und der vierte ist der teuerste, weil er sich nicht heilen lässt: Die Regulierungsanforderung wird erst nach der Anbieterwahl geprüft.

Compute-Entscheidungen

3:39 Werden wir konkret. Worauf läuft Ihr Anwendungscode? Fünf Kandidaten stehen zur Wahl, und die Auswahl beginnt mit einer Frage, die häufig übersprungen wird. Die Frage im letzten Satz ist die, die den Entscheidungsbaum aufspannt: Migrieren Sie eine bestehende Anwendung oder bauen Sie neu? Bei einer Migration ist der Weg mit den wenigsten Änderungen meistens der richtige — Sie verlagern das Risiko sonst gleich doppelt.

4:04 Bei einer Neuentwicklung stehen andere Kandidaten vorn. Diese Unterscheidung klingt banal und wird trotzdem übergangen, weil neue Systeme und Bestandssysteme oft in derselben Sitzung entschieden werden. Lesen Sie die rechte Spalte als Bedingungen. Die dritte und vierte Zeile bilden zusammen die eigentliche Kubernetes-Frage: Brauchen Sie Zugriff auf die Kubernetes-API und die Steuerebene — oder wollen Sie nur Container betreiben?

4:29 Das sind zwei völlig verschiedene Anforderungen, und nur die erste rechtfertigt den Betriebsaufwand. Die Fußzeile sagt es deutlich: Wer die API nicht braucht, sollte den verwalteten Container-Dienst prüfen. Gleiche Containerwelt, deutlich weniger Betrieb. Kubernetes ist ein hervorragendes System — für die Probleme, für die es gebaut wurde. Die vier Punkte hier sind die Rechnung.

4:52 Clusterpflege, Aktualisierungen und Absicherung bleiben Ihre Aufgabe, auch bei einem verwalteten Angebot. Für den Produktivbetrieb werden mehrere Knoten je Pool empfohlen, nicht einer — das ist eine Grundlast, die Sie unabhängig von Ihrer Anwendung bezahlen. Und die nötige Fähigkeit im Team ist Kubernetes-Betrieb, nicht Anwendungsentwicklung. Das sind verschiedene Menschen.

5:15 Hier möchte ich zu einer nüchternen Sicht einladen. Portabilität ist nicht kostenlos — sie bedeutet Verzicht auf die tief integrierten Dienste, die den größten Betriebsgewinn bringen. Und ein verwalteter Dienst spart Ihnen Betrieb, den Sie sonst selbst bezahlen müssten, in Personal. Die richtige Frage lautet deshalb nicht, ob Sie sich binden, sondern wie teuer ein Wechsel im Ernstfall wäre.

5:37 Eine Ausstiegsstrategie darf skizziert sein, ohne dass Sie sie regelmäßig üben. Wichtig ist nur, dass jemand die Zahl einmal geschätzt hat. Der zweite und dritte Punkt betreffen Kartenwerk direkt. Wenn die Anwendung lange zum Starten braucht, nützt automatische Skalierung beim Vorverkaufsstart nichts — bis die neuen Instanzen bereit sind, ist die Spitze vorbei.

5:59 Und eine zustandsbehaftete Anwendung verträgt keinen Knotenwechsel; wir hatten das bei den WebSockets in Modul drei. Der letzte Punkt ist eine häufige Fehlannahme: Anwendungsplattformen arbeiten je Region. Mehrere Regionen bedeuten mehrere Bereitstellungen plus etwas davor, das verteilt.

Cloud-native Entwicklungs- und Betriebsmodelle

6:17 Damit zum Betrieb selbst — und zu der These, dass die Art Ihrer Auslieferung Teil der Architektur ist und nicht etwas, das danach kommt. Drei Eigenschaften stecken hier drin, und die dritte ist die folgenreichste. Der gewünschte Zustand steht in der Versionsverwaltung — nicht im Kopf einer Person und nicht in einer Konsole.

6:36 Das klingt nach Werkzeugwahl und ist eine Aussage über Nachvollziehbarkeit: Jede Änderung hat einen Autor, einen Zeitpunkt und einen Grund. Unveränderliche Artefakte ergänzen das: Was getestet wurde, wird unverändert ausgeliefert. Beides zusammen macht Auslieferung von einem Ereignis zu einem Vorgang. Fünf Stationen — und die letzte ist die, die gern fehlt. Nach dem Rollout kommt Beobachtung, und zwar nicht als Kontrolle im Nachhinein, sondern als Teil der Auslieferung.

7:05 Ohne diese Station können Sie weder Canary noch automatischen Rückfall bauen, denn beide brauchen ein Signal. Deshalb schließt sich hier der Kreis zu Modul zehn: Observability ist nicht nur Fehlersuche, sie ist die Voraussetzung dafür, dass Ihre Auslieferungskette selbst entscheiden kann. Diese vier Punkte erklären, warum sichere Auslieferung nicht durch ein Werkzeug entsteht.

7:27 Blau-Grün und Canary verlangen eine Anwendung, die zwei Versionen nebeneinander verträgt — das betrifft das Datenmodell, die Nachrichtenformate, die Zwischenspeicher. Feature Flags trennen Auslieferung von Freischaltung und erzeugen dabei eine eigene Altlast, die niemand aufräumt. Und der letzte Punkt ist der, an dem Rollbacks tatsächlich scheitern: Eine Datenbankmigration, die nur vorwärts geht, macht jeden Rückweg unmöglich.

7:52 Der erste Punkt ist eine logische Folge, die oft übersehen wird: Wenn Konfiguration im Artefakt steckt, ist das Artefakt nicht mehr unveränderlich — dann bauen Sie je Umgebung neu und testen nie das, was Sie ausliefern. Geheimnisse gehören in einen Tresor, und der Zugriff darauf ist eine Identitätsfrage, keine Dateifrage.

8:11 Der letzte Punkt ist der, der im Ernstfall zählt: Wer Zugangsdaten rotieren will, muss es vorgesehen haben. Im Moment eines Vorfalls ist es dafür zu spät. Der erste Punkt hat einen Namen, den man sich merken sollte: Abweichung zwischen beschriebenem und tatsächlichem Zustand. Jemand greift einmal von Hand ein, und ab diesem Moment beschreibt Ihre Konfiguration eine Umgebung, die es nicht gibt.

8:34 Der zweite Punkt ist die halbe Canary: ausgerollt wird schrittweise, aber es gibt keine Kennzahl, die abbrechen könnte. Dann ist es kein Canary, sondern ein langsames Rollout mit besserem Namen.

Platform Engineering

8:46 Kommen wir zu einem Thema, das in den letzten Jahren stark gewachsen ist — und das häufig als Technikprojekt missverstanden wird, obwohl es im Kern ein Produktthema ist. Achten Sie auf die Formulierung: eine integrierte Sammlung von Fähigkeiten, die nach den Bedürfnissen ihrer Nutzer geschnitten und präsentiert wird. Die Nutzer sind hier Ihre eigenen Entwicklungsteams.

9:07 Der Zweck ist eine gleichbleibende Erfahrung beim Beziehen der üblichen Dienste — statt dass jedes Team dieselbe Grundarbeit erneut leistet. Das Wort „präsentiert" ist dabei kein Zufall: Eine Plattform, die vorhanden, aber unauffindbar ist, existiert für ihre Nutzer nicht. Hier steckt die eigentliche Denkbewegung. Eine Plattform wird nach Nutzerbedarf entwickelt, nicht nach Technikvorliebe — das heißt konkret: Sie reden mit den Teams, bevor Sie bauen.

9:33 Vorrang haben häufig gebrauchte Fähigkeiten ohne Unterscheidungswert; die individuellen Sonderfälle nicht. Golden Paths sind der empfohlene Weg, nicht der einzige erlaubte. Und der letzte Punkt nennt den Zweck in einem Wort: die kognitive Last der Teams senken. Alles, was diese Last erhöht, ist gegen den Zweck gebaut. Drei Ebenen, und die unterste kennen Sie vielleicht als DORA-Kennzahlen: Auslieferungsfrequenz, Durchlaufzeit, Wiederherstellzeit, Fehlerrate.

10:01 Die oberste ist die ungewöhnliche — Weiterempfehlung und aktive Nutzer, also Kennzahlen aus der Produktwelt, angewendet auf ein internes Werkzeug. Und die Fußzeile ist der Satz, den ich Ihnen mitgeben möchte: Wenn niemand die Plattform freiwillig benutzt, ist das ein Produktbefund. Nicht ein Schulungsbedarf und nicht mangelnde Disziplin.

10:22 Der zweite Punkt beschreibt, wie Golden Paths ihre Wirkung verlieren: Sobald sie verpflichtend werden, sind sie keine Empfehlung mehr, sondern eine Vorschrift — und Vorschriften erzeugen Umgehungen. Der dritte ist eine ehrliche Frage an jedes Plattformteam: Bauen Sie gerade etwas, das man kaufen könnte? Und der letzte Punkt ist die Konsequenz aus dem Produktgedanken: Eine Plattform ohne Verantwortlichen für die Nutzererfahrung wird zu einer Sammlung von Werkzeugen.

Wirtschaftlichkeit

10:48 Zum Abschluss die Frage, die Architektinnen und Architekten am seltensten gestellt bekommen und am stärksten beeinflussen: Was kostet das alles eigentlich? Total Cost of Ownership umfasst mehr als die Rechnung des Anbieters — auch Betriebspersonal, Bereitschaft, Werkzeuge, Einarbeitung und die Kosten eines möglichen Wechsels.

11:07 Der zweite Satz ist für uns der entscheidende: In der Cloud sind Kosten variabel und damit direkt von Entwurfsentscheidungen beeinflusst. Früher war Infrastruktur eine Investition, die einmal genehmigt wurde. Heute ist sie eine Größe, die Sie mit jeder Skalierungsregel und jeder Aufbewahrungseinstellung verändern. Vier sehr konkrete Stellen. Skalierungsregeln bestimmen, wie viel Leerlauf Sie dauerhaft bezahlen.

11:31 Jeder Sprung über eine Netzgrenze kann Übertragungskosten erzeugen — bei einem Zuschnitt in viele Dienste summiert sich das. Verwaltete Dienste kosten mehr pro Einheit und weniger an Personal, und welche Seite günstiger ist, hängt von Ihrem Gehaltsgefüge ab, nicht von der Technik. Und Telemetrie: Aufbewahrungsfristen für Protokolle sind ein eigener Posten, der gerne überrascht.

11:52 FinOps klingt nach Controlling und ist im Kern Sichtbarkeit. Kosten werden sichtbar gemacht, bevor sie im Quartalsbericht auffallen — und jeder Kostenblock bekommt einen Verantwortlichen im liefernden Team. Das ist die eigentliche Neuerung: Wer die Architektur entscheidet, sieht die Rechnung. Überprovisionierung ist dabei die häufigste und unauffälligste Verschwendung, weil sie nie zu einem Vorfall führt.

12:15 Und der letzte Punkt gilt hier wie bei den Qualitätszielen aus Modul zwei: Ein Ziel ohne Messung ist eine Absichtserklärung. Der zweite Punkt ist der ehrlichste Satz dieses Kapitels: Eigenbetrieb gilt als billiger, weil das Personal in einer anderen Kostenstelle steht. Das ist keine Rechnung, sondern eine Buchungsfrage — und sie führt regelmäßig zu Entscheidungen, die insgesamt teurer sind.

12:38 Der dritte Punkt: Eine Ausstiegsstrategie als Folie ist keine. Im nächsten Modul geht es um drei Themen, die dieselbe Eigenschaft teilen — sie lassen sich nicht nachrüsten: Sicherheit, Resilienz und Beobachtbarkeit.