Viele Kunden scheitern daran, die Kosten in der Public Cloud unter Kontrolle zu bekommen. Aber warum ist das ausgerechnet auf der Public Cloud der Fall? Was steckt hinter dem Begriff FinOps und warum sollten sich betroffene Unternehmen damit beschäftigen?
Neulich nahm ich an einem Kyndryl-internen Training teil, in dem es um die Strategie und neusten Portfolio Erweiterungen im Themenbereich FinOps ging. Dem Thema begegnet man bei uns in der Firma gerade ständig, sowohl in Deutschland als auch global. (Falls jemand den Begriff noch nicht gehört haben sollte, findet ihr hier eine gute Definition was dahinter steckt.)
In diesem Workshop fiel die Aussage, dass Kunden „Predictability“ und „Control” lieben – also Vorhersehbarkeit, Planbarkeit und Kontrolle. Aber in der Public Cloud würden sie das nicht bekommen. Viele Kunden, die schon signifikant die Public Cloud nutzen, hätten sogar ein sehr ernstes Problem mit dem Thema was die Planbarkeit und Kontrolle ihrer Ausgaben und Rechnungen für die Hyperscaler angeht. Dazu habe ich zunächst recherchiert, um herauszufinden, ob es dazu auch außerhalb unserer Firma ähnliche Meinungen und Beobachtungen gibt. Der Eindruck, den ich gewonnen habe, ist folgender:
Der Bedarf und die Nachfrage nach Lösungen und Konzepten, um die steigenden, und vor allem unkontrollierbaren Kosten der Hyperscaler in den Griff zu bekommen, scheint bei den Kunden, die schon intensivere Erfahrungen mit Public Clouds gemacht haben, immer größer zu werden. Manche Autoren berichten sogar schon von einem Trend, bestimmte Workloads wieder zurück ins eigene on-premise Rechenzentrum zu holen wie hier. Es wird auch berichtet, dass die Public Cloud in puncto Kosten die Erwartungen ziemlich enttäuscht hat, nachzulesen etwa hier.
Flexibilität verursacht Kosten
Seit vielen Jahren berate ich selbst Kunden im Themenkomplex „Journey to Cloud“. Ich habe die Architekturen dutzender Cloud-Zielumgebungen designt, Reviews durchgeführt und begleitet. Das überzeugende Argument für die Nutzung und die Migration auf eine Public Cloud war dabei immer die leichte Anpassbarkeit der Cloud Services auf schwankende und unvorhergesehene Anforderungen des Geschäfts sowie die einfache Nutzung für Entwickler und die Vielfältigkeit und Aktualität der Services, die den Verantwortlichen der Anwendungen und Geschäftsprozesse so viele Möglichkeiten und Freiräume bieten.
Die großen Hyperscaler bringen dazu eine Vielfalt an Funktionalität frei Haus mit, um die Performance zu überwachen aber auch die Security Settings und Controls und natürlich auch die anfallenden Kosten feingranular auf Mandanten, Organisationseinheiten und Projekte zuzuordnen. Ausgaben können in Echtzeit erfasst werden und es lassen sich sogar automatisiert Budgets auf User Ebene einrichten und verwalten. Diese Funktionalität und der Reifegrad dieser Tools und Services, um das Thema FinOps in Bezug auf Vorhersehbarkeit und Kontrolle in den Griff zu bekommen, übertrifft dabei bei weitem das was ich persönlich im Bereich der traditionellen Datacenter und IT Infrastrukturen – ob selbstbetrieben oder gehostet – gesehen habe.
Wenn aber die Tools und Funktionalitäten vorhanden sind – wo liegt dann das Problem?
Ich hab mir meine eigenen Gedanken gemacht und versucht einen Reim auf diese scheinbar widersprüchlichen Aussagen und Beobachtungen zu finden. Um diese Frage zu beantworten, bin ich dann einmal die typischen Use Cases und Personas einer produktiven Public Cloud durchgegangen und habe die Design-Thinking-Methode und Fragetechniken darauf angewandt.
Ein Beispiel:
- Ein Fachbereich definiert eine Anforderung, dass eine neue Applikation benötigt wird.
- Der Applikationsarchitekt identifiziert die funktionellen Anforderungen und wählt mit einem Team aus Cloud SMEs die aus seiner Sicht passenden Services der Public Cloud aus, um diese App zu implementieren.
- Ein Entwickler Team bekommt den Auftrag die App zu implementieren.
- Der Fachbereich fordert ein Budget an, das vom Controlling oder Einkauf geprüft und freigegeben wird.
- Nachdem die App getestet und implementiert wurde, wird die App produktiv geschaltet und an ein Betriebsteam übergeben das die App dann in der Public Cloud nach einem bestimmten Operating Model (zum Beispiel DevSecOps, CloudOps) betreibt.
- Wenn die App nicht richtig funktioniert, wird ein Incident-Management-Prozess angetriggert um die Fehler zu beheben.
Cloud-Ressourcen zurückfahren, aber wie?
Was passiert, wenn die provisionierten Cloud-Ressourcen gar nicht mehr oder zumindest nicht im geplanten Umfang benötigt werden? Gibt es in der Betriebsabteilung oder den Fachbereichen einen Prozess der angetriggert werden kann, um zu prüfen, ob ein beliebiger Service auch wieder deprovisioniert werden kann? Gibt es Verantwortliche, die die implementierte Architektur regelmäßig überprüfen, auf die aktuellen Anforderungen und technischen Möglichkeiten im Hyperscaler-Portfolio mappen und damit ein kontinuierliches Redesign, Resolutioning und Optimization der Landing Zone und Workloads ermöglichen? Welcher Prozess wird angestoßen, wenn am Ende des Monats auf der Rechnung des Hyperscalers Server stehen von denen keiner weiß, wer sie provisoniert hat und wofür sie gebraucht werden? Oder wen kann man fragen, warum zum Beispiel die Netzwerkkosten in Asien im letzten Monat um 300 Prozent gestiegen sind?
Jetzt könnte man natürlich festlegen das alle Ressourcen, die nicht klar zugeordnet werden können oder die nicht ausgelastet sind, einfach regelmäßig und automatisiert deprovisioniert oder verkleinert werden. Entsprechende Tools und Funktionen gibt es reichlich am Markt.
Aber wer trägt dann die Verantwortung, wenn eine geschäftskritische Anwendung im Unternehmen ausfällt oder aufgrund dieser Veränderung nicht mehr ausreichend performant ist?
Die Antwort auf diese Fragen ist, dass es nicht die eine Person geben kann, die für die Lösung dieser Herausforderungen verantwortlich gemacht werden kann. Vielmehr bedarf es eines orchestrierten Zusammenspieles aus unterschiedlichen Rollen und Skills in der IT Organisation eines Unternehmens wie beispielsweise:
IT Executive – Benötigt eine konsistente Sicht auf den Wert eines Cloud Service. Verbindet technische Entscheidungen mit den daraus resultierenden Geschäftsergebnissen.
IT Operations Manager – Identifiziert und bereinigt nicht ausgelastete Cloud-Ressourcen.
Financial Analyst – Analysiert und organisiert die Auswertung der Cloud Ausgaben.
Lead Architect / Engineer – Versteht die finanziellen Auswirkungen seiner Architekturentscheidungen und prüft diese kontinuierlich auf Potential zur Effizienzsteigerung.
Fazit
FinOps muss ein interdisziplinärer Prozess im Betriebsmodell einer Public Cloud sein, um den Herausforderung der Kostenkontrolle in der Public Cloud Herr zu werden. Das heißt im Betriebsmodell der Landing Zone und Workload-Verantwortlichen der Betriebsorganisation oder des beauftragten externen Service Providers müssen die Abläufe, die Rollen und Skills und die adäquaten, für die Zielumgebung passenden, Tools definiert und implementiert werden. Nur so schafft man es, die Vorteile der Public Cloud voll zu nutzen und gleichzeitig die Übersicht und Kontrolle über die Kosten zu behalten.
Viktor Greve – Executive IT Architect, Cloud Practice bei Kyndryl Deutschland