FinOps, Kostenarchitektur und Anbieter-Lock-in

Kosten als Architekturqualität

Abschnitt 2.7 (Sicherheit, Benutzbarkeit und mehr) führte Kosten unter den Qualitätsmerkmalen auf und empfahl, sie pro Arbeitseinheit auszudrücken. Im Rechenzentrum waren die Kosten weitgehend fix: Hardware wurde alle paar Jahre gekauft, und die Entscheidungen eines Architekten bewegten die Monatsrechnung kaum. In der Cloud ist jede Architekturentscheidung auch eine Kaufentscheidung, laufend getroffen von Engineers statt einmal im Jahr vom Einkauf. Eine gesprächige Service-Grenze, ein Debug-Log-Level, eine vergessene Testumgebung oder ein synchroner regionsübergreifender Aufruf taucht jeweils auf der Rechnung des nächsten Monats auf. Kosten sind zu einem Qualitätsmerkmal geworden, das sich mit jedem Deployment ändert.

Zwei Disziplinen helfen. FinOps ist die betriebliche Praxis, die Cloud-Ausgaben sichtbar, verantwortet und gesteuert macht. Kostenbewusste Architektur ist die Entwurfspraxis, die Systeme von vornherein günstig im Betrieb pro Werteinheit macht. Dieser Abschnitt behandelt beide und wendet sich dann ihrem unbequemen Nachbarn zu: dem Lock-in, also den Kosten des Ausstiegs.

FinOps: Phasen, Prinzipien und wer was tut

FinOps wird von der FinOps Foundation, einem Projekt der Linux Foundation, definiert als operatives Framework und kulturelle Praxis, die den Geschäftswert von Technologie maximiert, durch zeitnahe, datengestützte Entscheidungen und eine finanzielle Verantwortung, die Engineering, Finanzen und Fachbereiche teilen. Der Name spielt bewusst auf DevOps an: So wie DevOps die Mauer zwischen dem Bauen und dem Betreiben von Software eingerissen hat, reißt FinOps die Mauer zwischen dem Ausgeben von Geld und der Entscheidung ein, wie Software gebaut wird.

Das FinOps Framework gliedert die Arbeit in drei iterative Phasen. Inform (Informieren): Kosten sichtbar machen, sie den Teams und Produkten zuordnen, die sie verursachen, prognostizieren und vergleichen. Optimise (Optimieren): Verschwendung abbauen und Preise verbessern, durch Rightsizing, Zeitpläne, Nutzungszusagen und Designänderungen. Operate (Betreiben): die Gewohnheiten aufbauen, die Kosten unter Kontrolle halten, etwa Budgets, Richtlinien, Zuständigkeiten und Kosten als Kriterium jeder Designentscheidung. Organisationen durchlaufen den Zyklus wiederholt und reifen in jeder Fähigkeit von Crawl über Walk zu Run. Zu den Prinzipien des Frameworks gehört, dass Teams zusammenarbeiten, dass der Geschäftswert Technologieentscheidungen bestimmt, dass alle Verantwortung für ihre Technologienutzung übernehmen, dass Kostendaten zugänglich, zeitnah und korrekt sind, dass FinOps zentral ermöglicht wird und dass das variable Kostenmodell der Cloud vorteilhaft genutzt werden sollte. Neuere Versionen erweitern das Framework über die Public Cloud hinaus auf andere Technologieausgaben wie SaaS-Lizenzen, Rechenzentren und KI-Dienste.

Unit Economics: Kosten pro Bestellung

Eine Cloud-Rechnung, die von 80.000 auf 100.000 im Monat steigt, kann eine Katastrophe oder ein Triumph sein, je nachdem, ob das Geschäft um 5 % oder um 50 % gewachsen ist. Unit Economics drückt Kosten pro Einheit Geschäftswert aus: Kosten pro Bestellung bei der Essenslieferplattform, pro aktivem Kunden bei einem Streamingdienst, pro tausend API-Aufrufe bei einer Entwicklerplattform. Das trennt Effizienz von Wachstum, verbindet Engineering-Entscheidungen mit Geschäftsergebnissen und gibt Teams ein Ziel, das sie beeinflussen können.

Um das gut zu berechnen, braucht es drei Dinge. Erstens eine Einheit, die für das Geschäft zählt, gemeinsam mit Finanzen und Produkt gewählt, nicht von Engineers erfunden. Zweitens Kostenzuordnung: direkte Kosten (Rechenleistung und Datenbank des Bestellservice), zugeordnet über Tags oder Namespaces, und gemeinsame Kosten (die Kubernetes Control Plane, der Observability-Stack, die Werkzeuge des Plattformteams), aufgeteilt nach einer vereinbarten Regel wie der anteiligen Nutzung. Drittens eine Unterscheidung zwischen Durchschnitts- und Grenzkosten: Die durchschnittlichen Kosten pro Bestellung enthalten Fixkosten, die nicht mit den Bestellungen wachsen, daher sind die Kosten der nächsten tausend Bestellungen meist niedriger, als der Durchschnitt vermuten lässt, was bei der Preisgestaltung einer Aktion oder einer Wachstumsprognose wichtig ist.

Wohin das Geld fließt: häufige Kostentreiber

Die meisten überraschenden Cloud-Rechnungen gehen auf eine Handvoll Treiber zurück, und fast alle werden von der Architektur geprägt, nicht durch das Aushandeln besserer Preise.

Weniger für dieselbe Kapazität zahlen

Ist die Verschwendung beseitigt, lässt sich der Preis für die verbleibende Kapazität senken. On-Demand-Kapazität ist am flexibelsten und am teuersten. Ein Rabatt für Nutzungszusagen tauscht Flexibilität gegen Preis: AWS Reserved Instances und Savings Plans, Azure Reservations und Savings Plans sowie Google Cloud Committed Use Discounts bieten erhebliche Nachlässe (AWS nennt bis zu 72 % für manche Zusagen), wenn man sich für ein oder drei Jahre auf ein bestimmtes Nutzungs- oder Ausgabenniveau festlegt. Zusagen sollten nur die Grundlast abdecken, die für die Laufzeit sicher gebraucht wird; wer sich auf Spitzenkapazität festlegt, verwandelt einen Rabatt in Verschwendung.

Spot-Kapazität (AWS Spot Instances, Azure Spot Virtual Machines, Google Cloud Spot VMs) verkauft freie Kapazität mit hohen Rabatten, oft 60 % bis 90 %, doch der Anbieter kann sie kurzfristig zurückfordern: mit zwei Minuten Vorlauf bei AWS, etwa 30 Sekunden bei Azure und Google Cloud. Sie eignet sich für Arbeit, die zustandslos, unterbrechbar und wiederholbar ist, etwa Batch-Verarbeitung, CI-Runner, Rendering und manche zustandslosen Web-Schichten, die über viele Instanztypen verteilt sind. Sie eignet sich nicht für Datenbanken oder alles, was sich nicht mitten in einer Aufgabe stoppen lässt. Die Architektur entscheidet, wie viel einer Workload Spot nutzen kann: idempotente Jobs mit Checkpoints können es, lange, zustandsbehaftete nicht.

Tagging, Showback und Chargeback

Niemand optimiert Kosten, die er nicht sieht. Die Zuordnung beginnt mit einer Tagging-Richtlinie (oder Labeling-Richtlinie): Jede Ressource trägt einige wenige verpflichtende Tags, etwa verantwortliches Team, Service, Umgebung und Kostenstelle, durchgesetzt durch Guardrails im Infrastrukturcode und durch Richtlinien der Cloud-Organisation, denn von Hand vergebene Tags fehlen bald. Bei Kubernetes werden Kosten nach Namespace und Label zugeordnet, mit Werkzeugen wie dem Open-Source-Projekt OpenCost oder den Kostenzuordnungsfunktionen der Anbieter. Die FOCUS-Spezifikation der FinOps Foundation definiert ein gemeinsames Format für Abrechnungsdaten, sodass sich Kosten mehrerer Anbieter zusammenführen lassen.

Sind die Kosten zugeordnet, entscheidet eine Organisation, wie sie sie nutzt. Showback meldet jedem Team seine Kosten, ohne sein Budget zu berühren; das schafft Bewusstsein und ist der übliche Einstieg. Chargeback belastet das Budget jedes Teams mit den Kosten, was stärkere Anreize schafft, aber eine genaue Zuordnung, vereinbarte Regeln für gemeinsame Kosten und ein Verfahren für Streitfälle erfordert. In beiden Fällen gilt: Veröffentlichen Sie den Anteil der Ausgaben, der sich nicht zuordnen lässt; ein ungetaggter Anteil von mehr als ein paar Prozent bedeutet, dass die Zahlen noch nicht verlässlich genug sind, um danach zu handeln.

Architekturentscheidungen, die Kosten treiben

Die größten Einsparungen kommen aus dem Design, nicht aus Rabatten, und sie lassen sich am günstigsten erzielen, bevor ein System gebaut ist. Jede der folgenden Entscheidungen hat ein vorhersehbares Kostenprofil. Service-Granularität: Jeder Netzwerk-Hop kostet Rechenleistung, Serialisierung und eventuell Datenübertragung, daher kosten feingranulare Services in vielen Zonen pro Anfrage mehr als ein modularer Monolith. Synchroner Fan-out: Eine Anfrage, die zehn Services aufruft, hält für ihre Dauer elf Sätze von Ressourcen beschäftigt. Anzahl der Umgebungen: Vollständige Kopien der Produktion für jedes Team und jeden Branch vervielfachen die Rechnung; gemeinsame Umgebungen mit Isolation oder kurzlebige Previews kosten weit weniger. Datenaufbewahrung und Replikation: Jede zusätzliche Kopie und jede zusätzliche Region vervielfacht Speicher und Übertragung. Caching und CDNs: Ein Cache-Treffer ist meist weit billiger als eine Neuberechnung, und ein CDN-Treffer vermeidet Egress vom Ursprung. Rechenmodell: Serverless mit Abrechnung pro Anfrage ist unterhalb eines Schnittpunkts billiger als ständig laufende Kapazität und darüber teurer.

Halten Sie wesentliche Kostenfolgen in Entscheidungsdokumenten fest, neben den anderen Qualitätsabwägungen, und erwägen Sie, Kosten in die Fitness Functions aufzunehmen, die die Architektur absichern: zum Beispiel eine monatliche Prüfung, dass die Kosten pro Bestellung ohne Erklärung nicht um mehr als 10 % gestiegen sind.

Lock-in ist eine Abwägung, keine Sünde

Lock-in sind die Kosten und Schwierigkeiten, etwas zu verlassen, von dem man abhängt. Meist wird er als etwas diskutiert, das um jeden Preis zu vermeiden ist; Gregor Hohpes Artikel von 2019 auf martinfowler.com, Don't get locked up into avoiding lock-in, argumentiert, dass genau das selbst eine Falle ist. Er unterscheidet mehrere Arten von Lock-in: Anbieter (Verträge und kommerzielle Bedingungen), Produkt (die APIs und Funktionen eines bestimmten Produkts, auch wenn es Open Source ist), Version, Architektur (ein Stil wie Serverless), Plattform (Konten, Identitäts- und Sicherheitsmodelle), Fähigkeiten (was Ihre Leute können), rechtlich (Compliance und Lizenzierung) und mental (Annahmen, die Sie davon abhalten, Alternativen zu erwägen). Open-Source-Software verringert den Anbieter-Lock-in, lässt die meisten anderen Arten aber bestehen.

Der entscheidende Schritt ist, Lock-in als Problem der Optionsbewertung zu behandeln. Die Wechselkosten sind das, was ein Umzug kosten würde; multipliziert mit der Wahrscheinlichkeit, jemals umzuziehen, ergeben sie die erwarteten Kosten des Lock-ins. Die Wechselkosten zu senken hat seinen eigenen Preis: zusätzliche Abstraktion, Entwürfe auf dem kleinsten gemeinsamen Nenner und Verzicht auf Funktionen. Ein Wechsel, der 50.000 kosten würde und mit 5 % Wahrscheinlichkeit eintritt, hat erwartete Kosten von 2500, daher ist es ein schlechtes Geschäft, weit mehr auszugeben, um ihn zu vermeiden. Hohpes Matrix aus einzigartigem Nutzen und Wechselkosten macht daraus eine schnelle Einordnung.

Die Kosten der Portabilität und die Exit-Strategie

Portabilität ist nicht kostenlos. Jede Komponente so zu entwerfen, dass sie auf mehreren Clouds läuft, bedeutet, nur Funktionen zu nutzen, die alle gemeinsam haben, Abstraktionsschichten zu bauen und zu testen, die undicht sind (siehe Information Hiding und Leaky Abstractions), Know-how für mehrere Plattformen vorzuhalten und auf Managed Services zu verzichten, die Aufwand gespart hätten. Viele Multi-Cloud-Strategien enden mit den Kosten aller ihrer Anbieter und den Vorteilen keines einzigen. Am günstigsten ist Portabilität dort, wo es bereits offene Standards gibt: OCI-Container-Images, Kubernetes-Manifeste, PostgreSQL-kompatible Datenbanken, S3-kompatible Object-Storage-APIs, Standardprotokolle wie HTTP, AMQP und das Kafka-Protokoll sowie OpenTelemetry für Observability. Selbst die Werkzeuge, mit denen man portabel bleibt, etwa Terraform oder OpenTofu, sind für sich genommen Abhängigkeiten.

In der Praxis ist umstritten, wie weit man gehen sollte. Befürworter der Portabilität verweisen auf Preiserhöhungen, Ausfälle, Sanktionen, Regulierung und die Fälle, in denen sich der Auszug aus der Cloud gelohnt hat (siehe Cloud-Repatriierung in Abschnitt 10.1). Befürworter der Bindung an einen Anbieter verweisen auf die Geschwindigkeit und Zuverlässigkeit, die die volle Nutzung von Managed Services bringt. Eine solide Mittelposition ist, Lock-in bewusst dort zu akzeptieren, wo er klaren Nutzen bringt, die Geschäftslogik an den wenigen Nahtstellen, die sich am ehesten ändern, hinter Ports and Adapters unabhängig von Anbieter-APIs zu halten, Daten in exportierbaren Formaten zu speichern und eine Exit-Strategie schriftlich festzuhalten.

Regulierung verlangt diesen letzten Schritt zunehmend. Die EU-Verordnung über die digitale operationale Resilienz im Finanzsektor (DORA, Verordnung (EU) 2022/2554, anwendbar seit dem 17. Januar 2025; nicht zu verwechseln mit den DORA-Metriken für die Auslieferung) verpflichtet Finanzunternehmen zu Exit-Strategien für IKT-Dienstleistungen, die kritische oder wichtige Funktionen unterstützen. Die Regeln der EU-Datenverordnung (Data Act) zum Wechsel von Cloud-Anbietern gelten seit dem 12. September 2025: Kunden dürfen den Anbieter mit einer Frist von höchstens zwei Monaten wechseln, und Anbieter dürfen bis zum 12. Januar 2027 nur ihre direkten Wechselkosten berechnen, einschließlich Datenabfluss, danach gar nichts mehr. 2024 kündigten die größten Anbieter außerdem unter Bedingungen kostenlose Datenübertragung für Kunden an, die sie verlassen. Eine Exit-Strategie sollte für jeden kritischen Dienst den Ersatz benennen, Zeit und Kosten des Umzugs schätzen, zeigen, dass sich Daten in einem nutzbaren Format exportieren lassen, und zumindest teilweise geprobt werden, zum Beispiel durch das Wiederherstellen eines Backups in einer anderen Umgebung.