FinOps-Experten und technische Teams müssen enger zusammenarbeiten, um das Finanzreporting in ihre Architekturentwürfe, Taxonomien für Tags und Labels sowie andere Konfigurationen einzubeziehen. Tun sie das, kann ein Unternehmen erheblich davon profitieren. Tun sie es nicht, können die Folgen gravierend sein.
Die folgende Fallstudie verdeutlicht diese Notwendigkeit perfekt:
Kürzlich hatte unser großer Kunde aus dem Finanzdienstleistungssektor mit erheblichen Problemen bei der Verwaltung seiner Cloud-Ausgaben zu kämpfen. Die erste Herausforderung bestand darin, dass Cloud-Kosten überhaupt nicht auf Geschäftseinheiten umgelegt werden konnten. Noch problematischer war, dass es keine Möglichkeit gab, Kosten Produkten oder Kunden zuzuordnen, was eine genaue Berechnung der Bruttomargen für beide verhinderte. Das Unternehmen verfügte über etwa 25 Abrechnungskonten bei Cloud-Anbietern, doch 80 % der Ausgaben entfielen auf zwei davon. Trotzdem hatte es kaum Einblick, wofür dieses Geld ausgegeben wurde.
Außerdem wuchsen seine Cloud-Kosten im Verhältnis zu den Umsätzen überproportional, und das Unternehmen hatte den starken Verdacht, dass eine erhebliche Menge an Verschwendung diesen Trend vorantrieb. Der fehlende Einblick in die Ausgaben verhinderte jedoch, dass es die Ursachen der Verschwendung aufspüren und beseitigen konnte.
Wir begannen mit dem Kunden zusammenzuarbeiten, um das Problem anzugehen. Der Prozess begann damit, aus verschiedenen Geschäftsbereichen die richtigen Personen zu bestimmen, die in Teilzeit im FinOps-Team mitarbeiten sollten. Da sich die Ausgaben auf 20–25 Millionen US-Dollar pro Jahr beliefen, stellte das Unternehmen eine Person aus dem technischen Team zu 100 % für FinOps ab. Nachdem das Team zusammengestellt war, begann das Unternehmen mit der Analyse seiner Daten.
Zusammenarbeit mit dem FinOps-Team
Da FinOps-Praktiken von einer umfassenden und präzisen Segmentierung der Ausgaben abhängen, taten wir uns zunächst mit dem FinOps-Team des Kunden zusammen, um diese Herausforderung anzugehen. Das Team dokumentierte Namenskonventionen für Ressourcen und Tag-Werte, die verwendet werden konnten, um Ressourcen Geschäftseinheiten „zuzuordnen“. Diese Zuordnung wurde als Tabelle in der Datenbank angelegt. Mithilfe logischer „Wenn-dann“-Abfragen konnte das Team die Abrechnungsdaten um Informationen zur Geschäftssegmentierung anreichern und Berichte erstellen.
Im weiteren Verlauf konnte das Team einen höheren Anteil seiner Kosten Geschäftseinheiten zuordnen, bis es auf ein Hindernis stieß: Bestimmte Cloud-Dienste wurden als einzelne Positionen abgerechnet – konkret Rechenhosts, auf denen mehrere Container ausgeführt wurden –, dienten in Wirklichkeit jedoch mehreren Kunden und hosteten verschiedene Dienste. Anhand der Abrechnungsdaten ließ sich nicht feststellen, welcher Anteil dieser gemeinsam genutzten Ressourcen auf welche Produkte und Dienste entfiel.
Mittelfristig bestand die einzige Lösung darin, mithilfe einer API für die auf den Recheninstanzen ausgeführte Software (Kubernetes) einen separaten Bericht zu entwickeln. Die API ermöglichte es, die Auslastung bestimmter Container auf jedem Rechenhost zu verfolgen. Anschließend musste eine Leistungskennzahl ausgewählt werden, um den Anteil der von Kunden und Diensten verbrauchten Ressourcen eines Hosts zu bestimmen. Zu den erwogenen Optionen gehörten die CPU-Auslastung, die Menge des verwendeten Speichers, die Menge des reservierten Arbeitsspeichers und die Menge des verbrauchten Arbeitsspeichers.
Den Prozess betrachten
Man entschied sich, die von jedem Container reservierte Menge an Arbeitsspeicher als Kennzahl zu verwenden. Das war sinnvoll, denn unabhängig davon, ob ein Container seine gesamte Speicherzuweisung tatsächlich nutzte, stand diese Zuweisung anderen Containern nicht zur Verfügung und konnte daher als „genutzt“ betrachtet werden.
Mit anderen Worten: Wenn die Container für Kunde X 10 % des Arbeitsspeichers eines Hosts reservierten, wurden Kunde X 10 % der Host-Kosten „berechnet“. Der Prozess war effektiv, brachte jedoch mehrere Probleme mit sich:
- Er führte zu einem aufwendigen zusätzlichen Reporting-Aufwand für die Mitglieder des technischen Teams, der sie von ihren eigentlichen Aufgaben ablenkte.
- Die Erstellung des Berichts nahm Zeit in Anspruch und verzögerte jeden Monat die Erstellung eines vollständigen Kostenberichts.
- Die von den technischen Teams erstellten Berichte mussten mit den Daten aus der FinOps-Infrastruktur für das Kostenmanagement zusammengeführt werden, um Umlageberichte zu erstellen. Durch diese Nachbearbeitung hatten die Nutzer der Kostenmanagement-Tools des Unternehmens keinen Echtzeiteinblick in die Umlagewerte. Theoretisch konnten sie eine Kopie des fertigen Berichts anfordern, doch die Berichte wurden für Buchhaltungs- und Finanzzwecke nur monatlich erstellt.
Obwohl der API-basierte Behelfslösung den benötigten Bericht erzeugte, war der Prozess nicht nachhaltig. Das technische Team teilte dem FinOps-Team mit, dass die einzige echte „Lösung“ darin bestand, die „Namespaces“ der Workloads neu zu strukturieren, sodass die Kosten direkt in den Abrechnungsdaten verfolgt werden konnten.
Dieses Projekt war jedoch umfangreich genug, dass es in den gesamten Sprint-Zyklus des technischen Teams eingeplant werden musste und andere notwendige Entwicklungsprojekte verzögert hätte. Die überarbeiteten Namespaces wurden schließlich zwei Monate nach Beginn der Nutzung der API-basierten Behelfslösung implementiert und lösten das Problem.
Das Ergebnis war letztlich positiv. Das Unternehmen konnte seine Ausgaben segmentieren und Kosten Kunden, Diensten sowie den für deren Verwaltung zuständigen Engineering-Teams zuordnen. Dadurch konnte es Optimierungsinitiativen wesentlich effektiver umsetzen, aufgegebene Nicht-Produktiv-Workloads abschalten und seine Teilnahme an Rabattprogrammen von Anbietern optimieren, weil es von jeder verantwortlichen Stelle Nutzungsprognosen einholen konnte.
Das Ergebnis? Obwohl die Umsätze weiterhin im gleichen Tempo wuchsen, stabilisierten sich die Public-Cloud-Kosten. Das erstaunliche Resultat: Im ersten Jahr sparte das Unternehmen insgesamt 9 Millionen US-Dollar gegenüber dem Betrag, den die bisherigen Trendlinien für denselben Zeitraum prognostiziert hatten.
Trotz des positiven Ergebnisses erlangte das Unternehmen die Kontrolle über seine Cloud-Ausgaben erst nach Monaten oder Jahren mit so eingeschränkter Transparenz zurück, dass sich die insgesamt angefallene Verschwendung auf deutlich mehr als siebenstellige Beträge summierte.
Letztlich hätte sich diese Verschwendung vermeiden lassen, wenn das technische Team die Reporting-Anforderungen in seine technischen Architekturen einbezogen hätte. Es hatte die technischen Vorzüge jeder neuen Architektur berücksichtigt und bei seinen technischen Entscheidungen selbstverständlich auch die Kosteneffizienz einbezogen. Was es versäumte, war, diesem dreibeinigen Hocker ein „drittes Bein“ hinzuzufügen: die Reporting-Anforderungen.
Best Practice für die Architektur im Hinblick auf FinOps
Mit der zunehmenden Nutzung von Technologien für gemeinsam genutzte Ressourcen wie Containerisierung und gemeinsam genutzten Datenbank-Hosts wird auch der Bedarf an einer „FinOps-gerechten Architektur“ steigen. Lösungsarchitekten sollten FinOps-gerechte Architektur zu einer Standardpraxis machen, indem sie die folgenden Schritte umsetzen:
Bedarf ermitteln
Während der Architekturphase verschiedene Nutzer des Finanzreportings im Unternehmen zu ihren Reporting-Anforderungen für neue Workloads befragen. Im oben beschriebenen Fall hätte dies beispielsweise gezeigt, dass die Finanzteams die Kosten nach Kunden und nach Diensten messen müssten.
Mit diesem Wissen hätten sie von Anfang an ein Namespace-Schema für ihre containerisierten Workloads festlegen können, das diese Transparenz ermöglicht. Außerdem hätten sie erfahren, dass Demo- und Proof-of-Concept-Instanzen Kunden zugeordnet werden müssten, damit sie beendet werden können, sobald sie nicht mehr benötigt werden.
Lösungsarchitekten sollten denselben Fehler zunächst vermeiden, indem sie die verschiedenen Parteien identifizieren, die Berichte über Cloud-Ausgaben benötigen – etwa die Geschäftsleitung, die Finanzabteilung, die Buchhaltung, Product Owner und technische Teams. Mit diesen Personen sollten sie Arbeitssitzungen abhalten, um die erforderlichen Berichte zu erfassen. Dabei ist es wichtig, die Diskussionen auf die Reporting-Anforderungen zu konzentrieren und zwischen Berichten zu unterscheiden, die „nice to have“ sein könnten, und solchen, die „unverzichtbar“ sind. Der Aufwand für Erstere sollte dem Aufwand für Letztere untergeordnet werden.
Nichttechnische Dimensionen identifizieren
Anschließend sollten sie die nichttechnischen Dimensionen der Architektur identifizieren, die die Reporting-Anforderungen unterstützen. Dazu kann die Zuordnung von Organisationsstrukturen wie AWS-Abrechnungskonten, GCP-Projekten oder Azure-Ressourcengruppen zu den Reporting-Anforderungen gehören. Taxonomien für Tags und Labels, die diese Anforderungen unterstützen, sollten ebenfalls erstellt werden, wenn sie gegenüber Abrechnungsstrukturen vorzuziehen sind.
Entscheidend ist, dass Taxonomien für Tags und Labels stets „bedarfsgesteuert“ sein sollten. Das bedeutet, dass nur die Tag-Werte eingerichtet werden, die für notwendige Berichte benötigt werden. Die Belastung technischer Teams durch Tagging-Anforderungen sollte minimiert werden. Für das Labeling gilt ein altbekannter Management-Grundsatz: Das Messen geschäftlicher Aktivitäten verursacht Kosten. Wenn eine Kennzahl also keine Geschäftsentscheidung verändert, sollte sie nicht gemessen werden.
Automatisierung einsetzen
Setzen Sie nach Möglichkeit Automatisierung ein, um die korrekte Anwendung von Abrechnungsstrukturen (Abrechnungskonten usw.) sowie von Tags und Labels sicherzustellen. Nichts ist schlimmer als eine unzureichende Tagging-Abdeckung oder das Fehlen einer Hierarchie von Abrechnungsstrukturen – außer fehlerhaften Abrechnungsdaten!
Sobald Ressourcen in den falschen Abrechnungsstrukturen landen oder sich ungenaue Tag-Werte in den Daten ausbreiten, kann es äußerst schwierig sein, die Situation zu korrigieren.
Wichtige Szenarien identifizieren
Identifizieren Sie alle Szenarien, in denen die Reporting-Anforderungen eine Änderung bei der Nutzung der Cloud-Technologien selbst erfordern. Dies kommt am häufigsten vor, wenn gemeinsam genutzte Dienste wie containerisierte Workloads oder gemeinsam genutzte Datenbank-Hosts eingesetzt werden.
Überarbeiten Sie die Referenzarchitektur bei Bedarf, um sicherzustellen, dass die Reporting-Anforderungen erfüllt werden können.
Über den Autor:
Rich Hoyer ist Director of Customer FinOps bei SADA.