FinOps und Kubernetes – Best Practice Cloud-Kostenmanagement

In der Public Cloud erfolgt die Beschaffung von Ressourcen dezentral. Die Ausgaben sind dynamisch und aufgrund des Charakters der Cloud weniger vorhersehbar. Außerdem hat sich die Zahl der Kostenverursacher vervielfacht. Wer einen Account besitzt kann beim jeweiligen Cloudanbieter mit einem Mausklick Ressourcen kaufen. Es muss also eine neue Form des Kostenmanagements her, welches die Interessen und das Wissen von IT, Business und Controlling in Einklang bringt. Es braucht Methoden und Praktiken, die es den neuen Kostenproduzenten – den Entwicklern und Betreibern – ermöglicht, Cloud-Effizienz im täglichen Betrieb umzusetzen, anstelle zum Monats-/Jahresende Budgetüberschreitungen erklären zu müssen. Gleichzeitig müssen Business und Controlling mit der grundlegenden Funktionsweise von Cloud- und Containertechnologien vertraut gemacht werden, um informierte Diskussionen führen und Entscheidungen treffen zu können.Warum also der besondere Blick auf Kubernetes?
Die Arbeit mit Kubernetes erhöht das Abstraktionslevel im Vergleich mit der Public Cloud – und damit die Komplexität der Überwachung und Verwaltung von Cloud-Ausgaben aus der Perspektive der Interessen eines Unternehmens. Die Controller haben selten ein ausreichendes Verständnis vom variablen Cloud-Kostenmodell – wie sollen sie dann die Kubernetes-Welt verstehen?
Gleichzeitig bilden sich innerhalb der DevOps-Teams mit jeder technologischen Weiterentwicklung zunehmend schwerer aufzubrechende Wissenssilos über die Ressourcenverwendung. Cloudausgaben werden immer mehr zur Blackbox – und am Monatsende die Frage: wieso sind unsere Cloudkosten gestiegen?
Wie FinOps als neuer Kostenmanagement-Ansatz Unternehmen dazu verhelfen kann, auch mit neuen Plattformen wie Kubernetes Kontrolle über die Cloudausgaben zu gewinnen und mit welchen zentralen Strategien die entsprechenden DevOps-Teams zur Transparenz beitragen, wollen wir kurz vorstellen.
Wie der Kauf per Mausklick neue Herausforderungen schafft
Um die Relevanz dieses neuen Ansatzes zu verstehen, müssen wir ein wenig zurückgehen – in die Prä-Cloud-Zeit. Vor der Cloud hatten Unternehmen ihre eigenen Rechenzentren vor Ort. Wer sich an die Serie "The IT-Crowd" erinnert, hat Bilder von Kellern mit Servern und Büros voller Hardware im Kopf. Dieses Bild ist natürlich drastisch stereotyp, verbildlicht aber die grundlegende Organisation von IT-Ressourcen zu Cloudvorzeiten.
Die IT-Abteilung war für die Planung, Organisation und Wartung des Rechenzentrums verantwortlich. Hier liefen die Fäden zusammen, wenn es darum ging, zu entscheiden, was benötigt wird, sie entschied über die Hard- und Software und wann diese beschafft werden müssen. Teams und Projekte, die IT-Ressourcen benötigten, konnten Bedarfe anmelden, Ressourcen wurden entsprechend sorgfältig geplant und auf die Einkaufsliste gesetzt. Das Beschaffungswesen wickelte den Einkauf zentral ab und das Controlling war für die Planung und Kontrolle der Kosten zuständig. Die Kosten waren vorhersehbar, planbar und wurden als Kapitalaufwand betrachtet.
Mit der Public Cloud hat sich das alles geändert. Heutzutage kann jeder, der Zugang hat, Ressourcen ohne Absprache einkaufen und verwenden. Egal ob Architekt, Entwickler oder sogar Werkstudent! Unter dem Begriff "Pay-per-Use" erfolgt die IT-Beschaffung also nun per Mausklick. IT-Kosten sind plötzlich ungeplante Betriebsausgaben.
Mit Anbietern wie Amazon Web Services (kurz: AWS), Azure und Google Cloud Platform (kurz: GCP) können heute Lösungen, wie sie früher im eigenen Datencenter umgesetzt wurden, eins zu eins in der Cloud gebaut werden. Es wird sich also die Instandhaltung und die Hardwarebeschaffung gespart. Oder es wird gleich auf den gesamten Infrastrukturteil verzichtet und nur Software- oder Platform-as-a-Service genutzt. Durch die Managed Services der Anbieter lassen sich Workloads außerdem schneller umsetzen, flexibler skalieren und so weiter. Angebote wie Kubernetes nutzen ebenso die Beschaffung per Mausklick basierend auf der Cloud. Containerisierte Anwendungen können entweder basierend auf virtualisierter Infrastruktur in der Cloud verwendet werden oder aber als Managed Service direkt bei den Anbietern – wie etwa Amazon Elastic Container Service. Gleichzeitig steigt durch Kubernetes die Komplexität und Dynamik der verwendeten Ressourcen gegenüber der Cloud. Es kann noch rascher und flexibler und vor allem automatisiert skaliert werden. Kurzum: IT-Teams können nun selbst entscheiden, was und wann sie bereitstellen.
Warum Cloud- und Container-Kosten einen neuen Management-Ansatz brauchen
Die Möglichkeiten bringen große Chancen mit sich. Aber auch eine zunehmende Komplexität. Und damit einher geht noch etwas anderes: Kontrollverlust.
Denn mit dem Wachstum der Projekte wächst auch das Cloud-Ökosystem. Und damit auch ihre Komplexität bei der Überwachung. Dev-Teams verursachen heute Kosten via Code. Nicht-technische Teams erhalten die endlos langen Cloudrechnungen mit hohen, in der Regel steigenden Beträgen, die sie weder verstehen, noch sinnvoll der bisherigen Kostenallokation beifügen können.
Tatsächlich zeigen viele Umfragen, dass Cloud-Budgets von den Unternehmen überzogen werden und die Projektverantwortlichen keine Ahnung haben, was die Kostensteigerung verursacht [1;2]. Die Finanzabteilung ist aus dem Spiel und kann ihre Aufgabe des Controllings nicht wahrnehmen.
Warum FinOps?
Weil in der realen Welt aber eben in der Regel nicht-technische Personen (wie Finanzen, Controlling oder Management) über Budgetkürzungen und Investitionen entscheiden, ist es dringend notwendig, das Kostenmanagement von IT-Ressourcen auf zeitgemäße Weise anzugehen. Das Ergebnis ist eine Allianz von ITlern und Leidtragenden aus den unterschiedlichsten Bereichen, Branchen und Hierarchieebenen. Gemeinsam haben sie einen neuen Ansatz entwickelt, der eine Brücke zwischen den früher getrennten Unternehmensbereichen schlägt: FinOps.
Um es kurz zu machen: Bei FinOps geht es um Menschen, Daten und Werte.
FinOps ist keine (!) Abkürzung für "Financial Operations". Es ist die Erweiterung von DevOps um die Finanz- und Businessabteilungen. FinOps ist ein Rahmenwerk, bestehend aus Methoden, Leitlinien und Best Practices zur agilen Zusammenarbeit von Finance, Development und Operations. Es geht darum, die richtigen Leute an einen Tisch zu bringen, um über Cloud- und Container-Ausgaben so zu sprechen, wie in der Cloud gearbeitet wird: zeitnah, iterativ und zielgerichtet.
Das Ziel ist es, Cloud-Ausgaben und -Ressourcen transparent und zuweisbar zu machen und darüber hinaus den Wert der Public-Cloud-Nutzung für das Unternehmen zu steigern, indem konkrete Ineffizienzen aufgedeckt und Ansatzpunkte für die Optimierung gegeben werden. Kurzum: den maximalen geschäftlichen Wert aus der Public-Cloud-Nutzung für das Unternehmen auszuschöpfen.
FinOps zu praktizieren bedeutet, gemeinsam Standards und Prozesse zu etablieren, die es ermöglichen, Cloud- und Container-Kosten und -Nutzung projekt- und unternehmensübergreifend zu verstehen, zu verwalten und zu bewerten.
Warum FinOps bei den DevOps-Teams anfängt
In der Cloud sind wir es – die DevOps-Teams und die technischen Produktverantwortlichen –, die jede Minute des Tages Geld ausgeben. Und mit Abstraktionen wie Kubernetes werden wir mehr und mehr die Einzigen sein, die technisch und inhaltlich verstehen, wie welche Ressourcen Kosten produzieren. Damit werden wir diejenigen, die die Kosten erklären und argumentieren müssen. Eine Aussicht, von der unserer Erfahrung nach die allerwenigsten DevOps-Teams begeistert sind. Vor allem, wenn die Gegenseite der Argumentation aufgrund mangelnden technischen Wissens nicht folgen kann.
Die großen Fragen sind also:
- Wie können IT-Teams sicherstellen, dass sie dem Management nicht ständig über kostenbezogene Probleme berichten müssen?
- Wie können IT-Teams gleichzeitig genügend Transparenz und Kontrolle schaffen, damit sie das Budget für die Weiterentwicklung ihrer Produkte erhalten?
Kostenkontrolle ist in diesem Kontext der Schlüsselbegriff. Verbinden wir das nun mit FinOps.
Kostenkontrolle wird ermöglicht durch Kostentransparenz und Kostenoptimierung. FinOps ist in diesem Kontext das Rahmenwerk, das aufzeigt, wie und mit wem Transparenz und Optimierungsmöglichkeiten erreicht werden können. Dabei ist FinOps - genau wie Kubernetes bei Plattformen – agnostisch. Das macht es als Ansatz flexibel und anpassungsfähig und bietet Anleitungen, die dann an die Bedürfnisse der Unternehmensorganisation angepasst werden.
Wie DevOps-Teams FinOps praktizieren
FinOps bietet eine Reihe von Best Practices, die konkret aufzeigen, wie DevOps-Teams ihren weniger technischen Kollegen helfen können, Kostentransparenz, kontinuierliche Kostenüberwachung und -optimierung in ihren Sprints zu schaffen. Ohne daraus einen 24/7-Job zu machen.
Um dies zu erreichen, können DevOps-Teams vier Strategien in die alltägliche Arbeit integrieren:
- Monitoring
- Labeling
- Rightsizing
- Waste-Management
Denn um Kostentransparenz und -kontrolle in Kubernetes zu erreichen, muss nachvollziehbar sein, welche Anwendung oder welches Projekt wie viele der gemeinsam genutzten Ressourcen verwendet.
1. Monitoring:
Wenn es um Kostentransparenz geht, ist Monitoring unumgänglich. Und nicht nur die Arbeit mit Kubernetes macht den Einsatz von Monitoring-Tools unverzichtbar. Metriken wie CPU, RAM oder API-Aufrufe werden kontinuierlich zum Schutz der Sicherheit oder Resilienz der Anwendung überwacht. Kostenmetriken werden in den meisten Tools aber nicht miteinbezogen. In einer Umfrage der Cloud Native ComputingFoundation (kurz: CNCF) gaben 70 Prozent der Unternehmen an, ihre Kubernetes-Kosten kaum bis gar nicht zu überwachen [3].
Dabei mangelt es weniger an verfügbaren Daten. Oft werden die Performance-Daten im Monitoring-Tool einfach nicht mit den Kostendaten in einen Kontext gesetzt. Als Beispiel weist ungenutzte CPU auf ungenutzte Ressourcen hin, welche wiederum Kosten verursachen, die zu vermeiden sind. Aus diesem Grund ist das Monitoring von Clustern und Nodes der erste Schritt zur Kostentransparenz.
Ressourcen in Kubernetes sind üblicherweise geteilt; mehrere Teams lassen ihre Applikationen auf einem Node oder Cluster laufen. Damit ist eine Kostenzuordnung ausschließlich mithilfe des Kostenmonitorings nicht möglich. Es wird eine weitere Strategie – Labeling – benötigt, um die Kostentransparenz in Kubernetes zu ermöglichen.
2. Labeling:
Es gibt mehrere Möglichkeiten, Workloads zu kennzeichnen, aber am sinnvollsten ist ein Standard-Set an Labels zu entwickeln und deren Ausführung zentral zu entscheiden und zu automatisieren.
Der Schlüssel zum Erfolg ist: Es geht das Eine nicht ohne das Andere.
Wer Erfahrung mit der Bereitstellung von Cloud-Ressourcen hat, fragt sich vielleicht: Warum nicht einfach eine Label-Liste erstellen und für die eigenen Deployments automatisieren?
Die Antwort: Dieser Ansatz ist nicht nachhaltig. Denn in der Realität verwendet jedes Projekt sein eigenes Set an Labels, abgestimmt auf den Informationsbedarf der Mitwirkenden. Auf Organisationsebene oder im Monitoring-Tool entsteht so eine Vielzahl an Duplikaten, verschiedensten Schreibweisen, unterschiedlich nachvollziehbaren Informationen oder überhaupt kein Labeling – kurzum: Chaos.
Labels, die der Kostentransparenz dienen sollen, müssen also den Informationsbedarf mehrerer Stakeholder abbilden. Das bezieht Fragestellungen mit ein, wie zum Beispiel: "Wie effizient ist ein Projekt/eine Anwendung/...?“ oder "Was sind die kumulierten Ausgabentreiber während unserer Test-/Entwicklungsphasen?". Weiterhin braucht es klare Regeln, wie Labels umgesetzt werden. Bei fehlenden Standards in Schreibweise und Bezeichnung sind Labels für die Kostenallokation sonst unbrauchbar.
In der FinOps-Praxis haben sich die folgenden sechs Labels bewährt, um die meisten der Standardinformationen abzudecken, die im Zusammenhang mit Fragen des Kostenmanagements auftreten:
- Anwendung (application)
- Geschäftseinheit (business unit)
- Unternehmen (company/brand)
- Kostenstelle (cost center)
- Umgebung (environment)
- Projekt (project)
Dieses Set lässt sich natürlich beliebig ergänzen und verändern. Aber bei jedem neuen Label gilt: Bei der Beschreibung daran denken, dass nicht-technische Beteiligte sie auch verstehen müssen.
Labeling ist gerade bei geteilten Ressourcen wie Kubernetes von essenzieller Bedeutung. Ohne eine strukturierte und automatisierte Zuordnung der Pods zu einem bestimmten Projektteam oder Anwendung, lassen sich die dynamischen Workloads nicht nachhalten, weiterverrechnen oder optimieren.
3. Rightsizing:
Um Kontrolle über die Kubernetes-Kosten zu bekommen, ist Transparenz der erste notwendige Schritt. Auf Basis der Transparenz können Optimierungspotenziale aufgespürt werden und über die entsprechenden Metriken deren Erfolg gemessen werden. Rightsizing zielt hierbei auf die Optimierung der Auslastung von Ressourcen ab. Also genau die richtige Menge an Ressourcen einzusetzen – nicht mehr oder weniger.
In Kubernetes ist der Schlüssel zu optimal ausgelasteten Pods, Nodes und Clustern die richtige Verwendung von Autoscalern – also die automatisierte Auf- und Abwärts-Skalierung der Ressourcen. Viel mehr noch als Cloud-Ressourcen sind Kubernetes-Ressourcen auf diese Automatisierung angewiesen.
Listing: Beispiel einer Pod-Konfiguration mit Ressourcenanforderungen und -beschränkungen
---
apiVersion: v1
kind:Pod
metadata:
name: frontend
spec:
containers:
- name: app
image: images.my-company.example/app:v4
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
Richtig bedeutet in diesem Kontext, dass in der Pod-Konfiguration sinnvolle Ressourcenanforderungen definiert werden. Denn Kubernetes wendet standardmäßig keine Ressourcenbeschränkungen an und liefert den Autoscalern damit keine zuverlässigen Metriken, wenn es um genau die richtige Menge an benötigten Ressourcen geht. Wer den Schritt gegangen ist, kann die Autoscaler-Magie geschehen lassen und mit vertikalen und horizontalen Pod Autoscalern die Größe oder Anzahl der Pods nach Bedarf automatisiert anpassen. Oder über den Cluster Autoscaler die eigene Node-Auslastung optimieren.
Richtig gesetzte Ressourcenanforderungen in Kombination mit Autoscalern können so eine konstante Unterauslastung – und damit Geldverschwendung – vermeiden und trotzdem sicherstellen, dass für die Workloads immer ausreichend Ressourcen zur Verfügung stehen.
4. Waste-Management
Grundlegende Regel beim Waste-Management: Alles loswerden, was nicht genutzt wird. Bei tausenden von Ressourcen ist das nicht so einfach, wie es klingt. Automatisierte Clean-ups können hier wahre Wunder bewirken.
Eine weitere Form von "Waste" bezieht sich auf alles, was aus Performanzsicht zwar gut ausgelastet ist, aber aus operativer Sicht gegebenenfalls Verschwendung ist. Ein klassisches Beispiel sind Anwendungen, die nachts oder am Wochenende verfügbar sind, obwohl sie nicht genutzt werden. Hier können DevOps-Teams in Rücksprache Abschaltungen terminieren.
Zusammengefasst sind die Prinzipien von FinOps theoretisch einfach:
- Dinge loswerden, die nicht genutzt werden,
- Diskontierungsangebote der Cloudprovider nutzen (z. B. Reservierungen),
- Ressourcen optimieren, die nicht richtig genutzt oder ausgelastet sind (Rightsizing) und
- Prinzipien kombinieren und kontinuieren.
In der Praxis bedeutet dies aber einen organisatorischen Shift.
Wie FinOps Teil der täglichen Praxis wird
Wie an den oben beschriebenen Praktiken unschwer zu erkennen ist, geht es nicht ohne das Mitwirken der technischen Seite. Denn keine der beschriebenen Aktivitäten lässt sich ohne die IT-Teams bewerten und umsetzen. Zur Einführung von Kostenmonitoring, zur Identifikation und Bewertung von Einsparpotenzialen und zur sinnvollen Kostenallokation braucht es ein Team, das sich dem Thema widmet, im besten Fall eine Kombination aus Management- und Technologiewissen im und über das Unternehmen. Zusätzlich dazu braucht es Werkzeuge, die es ermöglichen, Performanz mit den Kosten zu verknüpfen. Gleichzeitig geht mit dem Shift von Kapital- zu Betriebsausgaben einher, dass die Betrachtung dieser kontinuierlich erfolgt.
FinOps ist keine einmalige Sache.
Das bedeutet auch: Kostentransparenz muss Teil der Anwendungsentwicklung und des Betriebs werden. Denn nur was in unseren Sprints Platz findet, wird auch irgendwann umgesetzt.
Und ganz konkret als Kubernetes-Team?
Gewährleisten, dass ein funktionales Monitoring möglich ist. Das bedeutet, neue Cluster und Nodes in das Kostenmonitoring mit einbinden, Labels ressourcenübergreifend standardisieren und ihre Umsetzung sicherstellen sowie realistische Ressourcenanforderungen definieren. Und bei all dem gilt: nicht nur für das eigene Team, sondern in Abstimmung mit allen.
Schlusswort
Dieser Artikel ist nur ein kleiner Einblick in die Welt von FinOps. Wir wollen DevOps-Teams, Finanzabteilungen und Produktverantwortliche dazu ermutigen, FinOps-Praktiken in ihren Arbeitsalltag mit aufzunehmen. Nicht nur, um Schweißausbrüche bei der Frage "Wieso sind die Cloudkosten gestiegen?", zu vermeiden. Sondern um Sicherheit durch Transparenz zu schaffen und gleichzeitig dort anzusetzen, wo es faktisches Einsparpotenzial gibt.
Und die Botschaft an das Management? Wer in der Cloud operiert, kommt um FinOps nicht herum.
Es spielt keine Rolle, ob cloud-native oder hybrid gearbeitet wird, ob mit einem Single-Cloud- oder Multi-Cloud-Ansatz, ob mit oder ohne Containertechnologien wie Kubernetes. Es spielt auch keine Rolle, wie groß ein Unternehmen ist oder in welcher Branche es tätig ist. Trotzdem wollen und müssen Unternehmen nach wie vor in der Lage sein, Ausgaben zuzuordnen, Kosten einzusparen und Budgets zu planen. Denn de facto gibt es in der Cloud schon heute mehr IT-Ressourcenvielfalt, -nutzung und -kosten als je zuvor.
Der richtige Moment, um mit FinOps im Unternehmen zu starten ist jetzt!