Cloud-Service- und Bereitstellungsmodelle

Von einer Definition zu vielen Modellen

Kapitel 0 hat Server und die Cloud eingeführt: die NIST-Definition (Special Publication 800-145, 2011) mit ihren fünf wesentlichen Merkmalen On-Demand-Selbstbedienung, breiter Netzwerkzugang, Ressourcenbündelung, schnelle Elastizität und gemessene Nutzung sowie die Idee, dass Servicemodelle mehr oder weniger vom Stack an einen Anbieter übergeben. Dieser Abschnitt vertieft diese Ideen so weit, wie ein Architekt es braucht, um zu entscheiden, wo ein System läuft, und diese Wahl zu verteidigen.

NIST definiert drei Servicemodelle (Infrastructure, Platform und Software as a Service) und vier Bereitstellungsmodelle: Public (für alle offen, im Besitz eines Anbieters), Private (für eine Organisation, egal wo sie steht und wer sie betreibt), Community (geteilt von Organisationen mit gemeinsamen Anliegen, etwa Behörden) und Hybrid (zwei oder mehr davon, so verbunden, dass Daten und Anwendungen zwischen ihnen wechseln können). Die Branche hat den Servicemodellen seitdem Functions und Containers as a Service hinzugefügt und dem Vokabular der Bereitstellung die Multi-Cloud.

Wo Software läuft, gehört zu dem, was Kapitel 1 die Zuordnungsstruktur einer Architektur genannt hat (Architektur definieren): die Abbildung von Software auf Hardware, Netzwerke und Organisationen. Bedeutsam im Sinne von Kapitel 1 ist sie, weil sie teuer rückgängig zu machen ist und weil sie einen Großteil der Kosten eines Systems festlegt, seine Verfügbarkeit, seine Sicherheitsgrenze und wie schnell seine Teams releasen können.

Servicemodelle: wer was verwaltet

Die Servicemodelle bilden ein Spektrum. Am einen Ende mieten Sie nackte Kapazität und erledigen alles darüber selbst; am anderen mieten Sie eine fertige Anwendung und konfigurieren sie nur. Jeder Schritt nach rechts nimmt Betriebsarbeit und Wahlmöglichkeiten weg. Die Tabelle ergänzt die zwei Modelle, die jünger sind als das NIST-Dokument: Containers as a Service und Functions as a Service.

In der Praxis verschwimmen die Grenzen. Serverless-Container-Plattformen wie Google Cloud Run und Azure Container Apps führen ein Container-Image so aus, wie ein PaaS Code ausführt, und skalieren wie eine Funktion auf null. Managed Kubernetes reicht von einer gehosteten Control Plane, bei der Sie die Worker-Maschinen weiterhin selbst patchen und aktualisieren, bis zu einem vollständig verwalteten Modus, in dem der Anbieter auch die Nodes betreibt. Die nützliche Frage ist nie, welches Etikett passt, sondern welche konkreten Aufgaben bei Ihnen bleiben: Patchen, Skalierungsentscheidungen, Kapazitätsplanung, Backups, Failover, Upgrades und Rufbereitschaft.

Eine zweite nützliche Unterscheidung ist die Einheit von Deployment und Abrechnung. IaaS rechnet Maschinen pro Sekunde oder Stunde ab, ob sie ausgelastet sind oder nicht; FaaS rechnet Aufrufe und Ausführungszeit ab und kostet im Leerlauf nichts; PaaS und Serverless-Container liegen dazwischen. Kapitel 6 erklärt, warum Abrechnung pro Anfrage unterhalb eines Schnittpunkts billiger ist als ständig laufende Kapazität und oberhalb teurer (Serverless-Architekturen). Die Form der Last einer Arbeitslast, nicht ihre Größe, entscheidet, auf welcher Seite des Schnittpunkts sie liegt.

Das Modell der geteilten Verantwortung

Jeder große Anbieter veröffentlicht ein Modell der geteilten Verantwortung. AWS fasst es so zusammen: Der Anbieter ist für die Sicherheit der Cloud verantwortlich, der Kunde für die Sicherheit in der Cloud. Der Anbieter sichert Gebäude, Hardware, Netzwerk, Hypervisor und die Dienste, die er betreibt; der Kunde sichert, was er darauf baut und konfiguriert. Wo die Grenze verläuft, hängt vom Servicemodell ab, wie das Diagramm zeigt.

Drei Dinge gehen nie über. Der Kunde besitzt immer seine Daten (was gespeichert wird, wo, wie lange, wer es lesen kann), seine Identitäten und Berechtigungen und die Konfiguration der Dienste, die er nutzt. Viele Cloud-Sicherheitsvorfälle gingen auf Konfigurationsfehler des Kunden zurück, nicht auf Fehler des Anbieters: für alle lesbarer Objektspeicher, Administratorschlüssel in öffentlichen Repositorys, zu weit gefasste Berechtigungen. 2019 etwa nutzte ein Angreifer bei Capital One eine falsch konfigurierte Web Application Firewall aus, um Cloud-Zugangsdaten zu erlangen und Daten zu mehr als 100 Millionen Menschen in den USA und Kanada zu kopieren; die Infrastruktur des Anbieters verhielt sich wie vorgesehen.

Für einen Architekten ist das Modell eine Checkliste von Arbeit, die jemandem zugewiesen werden muss. Verlegt ein Team die Bestelldatenbank der Essenslieferplattform von einer virtuellen Maschine in einen verwalteten Datenbankdienst, geht das Patchen der Datenbank-Engine an den Anbieter über, nicht aber die Wahl eines Wartungsfensters, das Testen von Hauptversions-Upgrades, die Vergabe von Zugriffen nach Least Privilege, das Aktivieren der Verschlüsselung und die Prüfung, ob sich Backups wiederherstellen lassen. Kapitel 8 behandelt die Sicherheitsprinzipien hinter diesen Pflichten ausführlich (Sicherheitsprinzipien für Architekten).

Bereitstellungsmodelle und die wirklichen Gründe dahinter

Organisationen wählen ein Bereitstellungsmodell selten aus nur einem Grund, und der genannte Grund ist nicht immer der wirkliche. Es hilft, die Motive, die einer Prüfung standhalten, von denen zu trennen, die es nicht tun.

Der verbreitete Fehler ist, Multi-Cloud als abstrakte Absicherung einzuführen. Eine Arbeitslast auf zwei Anbietern identisch laufen zu lassen, heißt, nur die Dienste zu nutzen, die beide anbieten, zwei Sätze Infrastrukturcode zu bauen und zu testen, Fachwissen für beide vorzuhalten und oft Gebühren für den Datentransfer zwischen ihnen zu zahlen. Das ist die Falle des kleinsten gemeinsamen Nenners: Sie zahlen jeden Tag die Kosten der Portabilität für einen Ausstieg, den Sie vielleicht nie nutzen. Abschnitt 10.8 behandelt Lock-in als Abwägung, die zu bepreisen ist, nicht als Sünde, die um jeden Preis zu vermeiden ist (FinOps, Kostenarchitektur und Anbieter-Lock-in).

Regionen und Availability Zones als Entwurfsgrößen

Eine Region ist ein geografisches Gebiet mit einem eigenen, unabhängigen Satz von Rechenzentren; eine Availability Zone besteht aus einem oder mehreren Rechenzentren innerhalb einer Region mit eigener Stromversorgung, Kühlung und Vernetzung, so weit von den anderen entfernt, dass ein Brand, eine Überschwemmung oder ein lokaler Stromausfall nur eine trifft, und nah genug für Round Trips von höchstens wenigen Millisekunden. Kapitel 0 hat die Idee erklärt. Für den Entwurf zählen drei weitere Punkte.

Erstens hat jeder verwaltete Dienst einen Ausfallbereich: Zonale Ressourcen (eine einzelne virtuelle Maschine, ein Datenträger) fallen mit ihrer Zone aus; regionale Dienste (die meisten verwalteten Datenbanken im Multi-Zonen-Modus, Objektspeicher, Queues) repliziert der Anbieter über Zonen; einige wenige globale Dienste (DNS, Identität, manche Content-Delivery- und Load-Balancing-Dienste) erstrecken sich über Regionen, was ihre seltenen Ausfälle weitreichend macht. Zu wissen, welchen Bereich jede Abhängigkeit hat, ist der erste Schritt jeder Verfügbarkeitsanalyse (siehe Verfügbarkeit und Zuverlässigkeit).

Zweitens ist die Verteilung über Zonen der günstige, wertvolle Standard. Laufen die zustandslosen Services der Essenslieferplattform in drei Zonen hinter einem Load Balancer, mit einer Datenbank, die einen synchronen Standby in einer zweiten Zone hält, übersteht die Plattform den Verlust eines Rechenzentrums mit automatischem Failover und geringen Latenzkosten. Drei Zonen statt zwei sind wichtig für alles, was Quoren nutzt, etwa etcd in Kubernetes oder eine konsensbasierte Datenbank, denn eine Mehrheit muss überleben. Verkehr zwischen Zonen ist allerdings nicht immer kostenlos: Die meisten großen Anbieter berechnen Datenübertragung zwischen Zonen, sodass gesprächige Services, die über Zonen verteilt sind, eine sichtbare Zeile auf der Rechnung hinzufügen.

Drittens sind Regionen nicht identisch. Neueren oder kleineren Regionen fehlen womöglich Dienste, manche haben weniger Zonen, die Preise unterscheiden sich je Region, und die Rechtsordnung folgt der Region. Abschnitt 10.6 behandelt mehrere Regionen, Disaster Recovery und Datenresidenz (Multi-Region, Disaster Recovery und Edge Computing).

Managed Services oder Eigenbetrieb

Ein Managed Service ist eine Komponente (eine Datenbank, Queue, ein Cache, eine Suchmaschine, eine Kubernetes-Control-Plane), die der Anbieter für Sie installiert, betreibt, patcht, sichert und skaliert. Die Alternative ist, dieselbe Open-Source-Software selbst auf virtuellen Maschinen oder in Containern zu betreiben. Die Abwägung lautet Arbeit und Risiko gegen Kontrolle, Kosten und Portabilität.

Managed Services gewinnen, wenn die Komponente nicht differenzierend ist: Jedes Essenslieferunternehmen braucht eine zuverlässige PostgreSQL-Datenbank, aber keines gewinnt Kunden dadurch, wie es Datenbank-Patches einspielt. In der Sprache des Domain-Driven Design sind das generische Subdomänen, die man kaufen statt bauen sollte. Eine verwaltete Datenbank bietet Multi-Zonen-Failover, Point-in-Time-Recovery und Patches für Nebenversionen, die sonst ein qualifiziertes Team in Rufbereitschaft bräuchten. Der Eigenbetrieb gewinnt, wenn Sie eine Version, Erweiterung oder einen Tuning-Parameter brauchen, den der Anbieter nicht anbietet, wenn seine Limits oder Kontingente nicht passen, wenn der Aufpreis für den verwalteten Dienst im großen Maßstab hoch wird oder wenn Portabilität über Umgebungen wichtiger ist als Bequemlichkeit.

Verwaltet heißt nicht wartungsfrei. Der Anbieter erzwingt Hauptversions-Upgrades nach seinem eigenen Zeitplan, wenn alte Versionen das Ende des Supports erreichen, ändert Standardeinstellungen, setzt Kontingente, die Sie im ungünstigsten Moment entdecken, und hat Ausfälle, die Sie nicht beheben, sondern nur aussitzen können. Bei Ihnen bleiben Schemadesign, Abfrageleistung, Kapazitätsentscheidungen, Kosten und der regelmäßige Test, der beweist, dass eine Wiederherstellung funktioniert. Behandeln Sie jeden Managed Service als Abhängigkeit mit eigenen Ausfallarten und eigenen Ausstiegskosten.

Was Cloud-native bedeutet

Die Cloud Native Computing Foundation (CNCF), Teil der Linux Foundation und Heimat von Kubernetes, veröffentlicht die meistzitierte Definition von Cloud-native. Version 1.0 (2018) beschrieb Technologien, mit denen Organisationen skalierbare Anwendungen in dynamischen Umgebungen wie Public, Private und Hybrid Clouds bauen und betreiben können, und nannte Container, Service Meshes, Microservices, Immutable Infrastructure und deklarative APIs als typische Beispiele. Version 1.1, 2024 verabschiedet, verlagert den Schwerpunkt von Technologien auf Praktiken: Arbeitslasten programmatisch und wiederholbar im großen Maßstab zu entwickeln, zu bauen und zu deployen, gekennzeichnet durch lose gekoppelte Systeme, die auf sichere, resiliente, verwaltbare, nachhaltige und beobachtbare Weise zusammenwirken.

Daraus folgen zwei Dinge. Cloud-native beschreibt, wie ein System gebaut und betrieben wird, nicht wo: Ein Kubernetes-Cluster in einem privaten Rechenzentrum, aus Code bereitgestellt und viele Male am Tag deployt, ist Cloud-native; eine von Hand konfigurierte virtuelle Maschine, unverändert in eine Public Cloud kopiert, ist es nicht. Und Cloud-native ist ein Mittel, kein Zweck. Seine Praktiken (Automatisierung, wegwerfbare Komponenten, deklarative Konfiguration, Elastizität, Observability) zahlen sich aus, wenn ein System häufige Änderungen, schwankende Last und hohe Verfügbarkeit braucht; für ein stabiles internes Werkzeug, das zwanzig Menschen nutzen, bringen sie Kosten und Komplexität.

Migrationen werden oft mit den sechs Rs beschrieben, die man kennen sollte, weil sie Erwartungen setzen: Rehost (Lift and Shift, unverändert), Replatform (kleine Änderungen wie der Umzug auf eine verwaltete Datenbank), Refactor oder Re-Architect (Neuentwurf für Cloud-nativen Betrieb), Repurchase (durch SaaS ersetzen), Retain (lassen, wo es ist) und Retire (abschalten). Rehosting geht schnell, bringt aber typischerweise wenige Vorteile der Cloud und kann, auf ständig laufenden, für die Spitze dimensionierten Maschinen, mehr kosten als das Rechenzentrum, das es verlassen hat.

Wann die Cloud nicht billiger ist

Das bekannteste Gegenbeispiel ist 37signals, das Unternehmen hinter Basecamp und HEY. Im Oktober 2022 kündigte sein Technikchef David Heinemeier Hansson den Abschied aus der Cloud an und verwies auf eine jährliche AWS-Rechnung von mehr als 3 Millionen USD für Arbeitslasten mit gleichmäßiger, vorhersehbarer Last. Das Unternehmen kaufte Dell-Server für rund 700.000 USD, stellte sie in gemietete Colocation-Flächen und zog seine Anwendungen 2023 von AWS-Rechenkapazität ab; nach eigenen Angaben senkte das seine Cloud-Rechnung um etwa 2 Millionen USD pro Jahr. 2025 kündigte es die zweite Stufe an: etwa 18 Petabyte an Dateien von Amazon S3 auf Storage-Arrays für rund 1,5 Millionen USD zu verlagern, um eine S3-Rechnung von etwa 1,5 Millionen USD pro Jahr zu ersetzen, mit dem erklärten Ziel, sein AWS-Konto zu schließen. Das Unternehmen hat Einsparungen von etwa 10 Millionen USD über fünf Jahre prognostiziert. Arbeitslasten auf diese Weise aus der Cloud zurückzuholen, nennt man Cloud-Repatriierung.

Beide Seiten verdienen Gehör. Für die Überlegungen von 37signals spricht: Die Last ist gleichmäßig, Elastizität brachte also wenig; das Unternehmen beschäftigte bereits erfahrene Betriebsfachleute und brauchte nach eigenen Angaben kein zusätzliches Personal; Colocation-Anbieter kümmern sich um Strom, Kühlung und physische Sicherheit; und Server lassen sich fünf Jahre oder länger nutzen, sodass ihre Kosten pro Rechenjahr weit unter der On-Demand-Miete liegen. Dagegen spricht: 37signals ist ein reifes Unternehmen mit vorhersehbarer Nachfrage, was die meisten neuen Produkte nicht sind; der Vergleich hängt stark davon ab, wie hoch die Cloud-Rechnung mit Rabatten für Nutzungszusagen und richtiger Dimensionierung gewesen wäre; eigene Hardware bedeutet Investitionsausgaben, Lieferzeiten von Wochen oder Monaten und im Voraus gekaufte Kapazität; und ein kleineres Team ohne tiefes Betriebswissen müsste solches einstellen, was die Einsparung zunichtemachen kann. Kritiker weisen außerdem darauf hin, dass die Zahlen zu den Einsparungen vom Unternehmen selbst stammen.