Zum Abschluss meiner Artikelserie rund um Kostenfallen in den verschiedenen Phasen der Cloud-Einführung möchte ich auf die Phase des Cloud-Workload-Betriebs eingehen. Trotz Selektion geeigneter Workloads und Berücksichtigung der Unternehmensanforderungen an Migration und Zielplattform finden gibt es auch hier Fallstricke, die häufig zu unerwarteten Cloud-Kosten führen:
- Komplexitätssteigerung im Betriebsmodell und bei Service-Integration
- Unkontrollierte und ineffiziente Cloudnutzung
- Hoher Aufwand durch mangelnde Transparenz
Komplexitätssteigerung im Betriebsmodell und bei der Service-Integration
Hier entstehen unerwartete Kosten vornehmlich aus der Komplexitätssteigerung im Betrieb. Die bisherige IT wird nicht einfach durch einen Cloud-Provider ersetzt, sondern Cloud entsteht parallel. Zudem bleibt es für viele Unternehmen nicht bei einem Cloud-Provider. Die meisten meiner Kunden sind heute schon bei mindestens zweiProvidern -Tendenz steigend.Von daher brauchen Unternehmen ein neues Service-Integrations-und Governance-Modell, das in der Lage ist, die Provider -so wie sie kommen -möglichst nahtlos in das eigene IT-Business zu integrieren.
Dafür braucht man neue Rollen, neue Skills und neue Prozesse. Als Beispiel sei hier der Managed Service erwähnt. „Cloud is an all managed service“ ist so absolut formuliert und zumindest bisher nicht zutreffend. Selbst wenn man einen Container-Service aus der Cloud bezieht, kann es sein, dass man noch immer selbst für die Konfiguration und das Patching der Workernodes verantwortlich ist, ganz abgesehen von der Integration in eigeneUmsysteme.Cloud Services sollen nicht isoliert irgendwo im Unternehmen benutzt werden, sondern gliedern sich idealerweise nahtlos in ein übergreifendes Monitoring, Eventmanagement, Incident/Problem/Change-Management etc. ein. Ein solches Modell zu schaffen, bedeutet zunächst einmal neue Tools und neue Integrationen und kann in unterschiedlichen Varianten umgesetzt werden.
Zusätzlich zum bisherigen ITIL Betrieb der traditionellen Umgebungen entstehen neue DevSecOps-Ansätze zum Betrieb der Cloud-Services mit eigenen Tools, Verfahren und Skills. Egal für welches der obigen Organisationsmodelle man sich entscheidet, es werden weiterhin Menschen in ausreichender Zahl und mit entsprechendem Know-How benötigt. Man erlebt immer wieder, dass dies zu Beginn einer Cloud-Transformation nicht klar ist und in der Regel erst spät zu bösem Erwachen führt.
Auch dies lässt sich an der bereits genutzten Auto-Analogie aus den vorherigen Artikeln sehr gut verdeutlichen. Wenn man sich ein Auto kauft und in die Garage stellt, hat man genau einen Beschaffungsweg. Aus Kaufpreis, Steuer und Versicherung ergeben sich feste, planbare monatliche Kosten. Mit einem Blick in die Garage stellt man fest, ob das Auto verfügbar ist und der Blick auf das Tachometer verrät den Kilometerstand. Bei Nutzung verschiedener Transportservices ergeben sich bereits unterschiedlichste Beschaffungswege wie z. B. der Telefonanruf bei der Taxizentrale, Flug-bzw. Zugbuchung im Webportal oder die Nutzung einer Handy-App für Car Sharing. Um dieVerfügbarkeit einzelnerServices oder deren aktuelle Auslastung festzustellen, sind ebenso viele unterschiedliche Wege notwendig. Als Vorgriff auf die beiden folgenden Abschnitte: Wenn man sich einen Überblick über monatliche Transportkosten verschaffen möchte, muss manRechnungen aus unterschiedlichsten Quellen und unterschiedlichster Formate zusammenführen.Wäre es nicht großartig, wenn man eine Anlaufstelle hätte, die zu einem gewünschten Zielort den optimalen Transportservice unter Abwägung von Geschwindigkeit, Zeit, Kosten, etc. vorschlägt?Damit ist man dann beim „Multi-Cloud-Management“ bzw. einer „Cloud-Management-Plattform“.
Unkontrollierte und ineffiziente Cloud-Nutzung
Der gewollt leichte Zugang zu Cloud Services führt zu einem Wiederaufleben des alt-bekannten Phänomens „Shadow IT“und damit zu unkontrollierter Cloudnutzung. Wer IT-Ressourcen benötigt, kann sie einfach in der Cloud beziehen. „Sourcing“ erfolgt nun plötzlich dezentral mit der Folge, dass IT-Budgets nicht mehr zentral, sondern ebenfalls dezentral („projekt-orientiert“)verwaltet werden.Das sorgt zwar vielfach für mehr Geschwindigkeit, allerdings bleiben Synergien und Kontrolle damit auf der Strecke:
- Keine zentralen Einkaufskonditionen
- Kein einheitliches Kontrollinstrument, um Kosten zu überwachen
- Kein übergreifendes Know-How, wie Cloud Services möglichst effizient genutzt werden
- Kein Überblick und damit keine Steuerungsmöglichkeit auf Unternehmensebene
- „Multi-Single“-Cloud: Abhängigkeit von einzelnen Cloud Providern in unterschiedlichen Fachbereichen wird erhöht
Ineffiziente Cloud-Nutzung entsteht im Wesentlichen aus zwei ebenfalls alt-bekannten Verhaltensmustern:
- „Was ich habe –behalte ich und gebe es so schnell nicht mehr her“: In traditionellen Umgebungen war es nicht leicht und häufig langsam, Zugriff auf dringend notwendige IT-Ressourcen zu erhalten. Wenn sie dann endlich verfügbar waren, wurden sie nicht mehr freigegeben. Die Rahmenbedingungen haben sich mit Cloud zwar geändert: Systeme können einfach bestellt werden und sind in kürzester Zeit verfügbar. Aber das Verhalten hat sich häufig (noch) nicht geändert und den neuen Möglichkeiten angepasst.
- Im Artikel zur Selektion geeigneter Workloads für die Cloud wurde auf „Variabilität“ als eine Stärke von Cloud-Services hingewiesen. Nur, das muss natürlich auch (aus)genutzt werden und passiert erfahrungsgemäß häufig nicht. Durch die Flexibilität von Cloud-Services ist kein initiales Sizing auf eine „vermutete“ Spitzenlast mehr notwendig. Man fängt klein an und wächst analog zum tatsächlichen Bedarf mit.Besser noch, bei rückläufigem Ressourcen-Bedarf lassen sich ungenutzte Kapazitäten wieder zurückgeben („right-sizing“) und nicht mehr benötigte Services sogar ganz abschalten. Bei einigenKunden fanden sich bis zu 60% Überkapazitäten in der Cloud. Bei monatlich teilweise über 2 Millionen Euro Cloudkosten stellt dies ein relevantes Einsparpotential dar, auch wenn am Ende nur 20-30% Kapazitäten eingespart werden können. Diese Betrachtung schließt im Übrigen auch sogenannte „Zombie“ Services ein. Gerade bei Cloud Services gibt es häufig ein Geflecht von Services, die voneinander abhängig sind. Wenn ein Service nicht mehr gebraucht und abgekündigt wird, kann es dazu führen, dass einzelne Services (z.B. anhängende Storage Services) „vergessen“ werden und dann weiter Kosten verursachen, obwohl sie nicht mehr genutzt werden.
Letztendlich gilt es den Überblick zu behalten und Transparenz zu schaffen, womit man beim dritten Punkt wäre.
Hoher Aufwand durch mangelnde Transparenz
Eine häufig mit Kunden diskutiertesProblem ist die verursachergerechte Weiterverrechnung von Cloudkosten. Dabei geht es noch nicht um das Optimieren der Cloudkosten, sondern darum die anfallenden (nicht optimierten) Kosten zunächst einmal richtig zu zuordnen. Warum ist das ein Problem?
Anfänglich ist das ggf. noch mit Tabellenkalkulationen handhabbar, aber irgendwann wird es unübersichtlich, vor allem wenn mehrere Cloud-Service-Provider genutzt werden. Die Fragmentierung der Datenquellen wird dadurch weiter verstärkt. Zudem verwenden die Provider sehr unterschiedliche Rechnungsformate, benennen und klassifizieren ihre Services bzw. „Line Items“unterschiedlich. Mit zunehmender Cloudnutzung enthalten die Rechnungen dann viele „Line Items“mit durchschnittlich geringenBeträgen. Die Rechnung eines Kunden mit monatlich rund1,5Millionen Euro Cloudkosten erstreckte sich beispielsweise über 500.000 „Line Items“. Dies war mit der Tabellenkalkulation nicht mehr handhabbar und wurde einfach bezahlt.Diese hohe Kleinteiligkeit verursachte nicht nur einen hohen Aufwand bei der Zuordnung zu den Kostenverursachern, sondern führte auch dazu, dass Reports zu spätverfügbar sind, um z. B. als aktives Steuerungselement bei dynamischen Kostenverläufen eingesetzt werden zu können (also z. B. zur frühzeitigen Eindämmung von unkontrollierter oder ineffizienter Cloudnutzung).
Der Aufbau eines Cloud-Service-Provider übergreifenden Data Lakes bildet hier aber lediglich die Basis zur Schaffung der notwendigen Transparenz imCloud Service Betrieb. Es sind intelligente Analyse-Werkzeuge notwendig, die darauf aufsetzen und Auswertungen über beliebige Provider durch die entsprechenden Daten aus dem Data Lake erstellen können. Idealerweise können sie auch die unterschiedlichen Datenformate für Services, Klassen, Tags und Abhängigkeiten so normieren, dass providerübergreifende Analysen möglich sind. Wenn diese Analysen dann noch „ad-hoc“ verfügbar sind, erhält man ein pro-aktives Steuerungselement zur Optimierung der Cloudnutzung.
Der beste DataLake und Analysetools sind jedoch nutzlos, wenn Datenquellen nicht hergeben, was zur Analyse gebraucht wird. Gerade wenn es um eine Zuordnung von Cloud-Ressourcen zu Projekten, Abteilungen, Anwendungen etc. geht, ist ein gutes Tagging, also das Versehen der Ressourcen mit Schlagworten, unabdingbar. Nur mit dem richtigen Tag ging, am besten auf Basis einer unternehmensweitenStrategie, ist eine korrekte Zuordnung und damit bedarfsgerechte Optimierung möglich.
Aktuelle KI-basierte Werkzeuge liefern auf dieser Basis nicht nur einfache Analysen zur Kapazitätsoptimierung z. B. durch die Korrelation von Auslastung und Kosten, sondern z. T. auch Architekturempfehlungen zur Nutzung der Services, wie z. B. die Ablösung von IaaS durch PaaS Bausteine.
