Wie amortisieren sich Cloud-Projekte? Laut einer Studie der Information Systems Audit and Control Association (ISACA) von Anfang 2018 verzichten 32 Prozent der Unternehmen darauf, den Return-on-Investment (ROI) zu berechnen – Tendenz steigend. Warum ist das so? - Zwar versucht im Grunde jeder Anwender, sich einen Überblick über die Rentabilität zu verschaffen. Allerdings gilt es, zahlreiche Einflussfaktoren zu berücksichtigen, um die Kostenstukturen zu erfassen. Die Folge: Cloud-Projekte scheitern bereits im Ansatz, weil sie auf falschen Kostenschätzungen beruhen. Naivität oder schlicht mangelnde Erfahrungen im Cloud-Umfeld kommen hinzu.

Ein Praxisbeispiel: Ein Kunde entdeckt, dass er eine Oracle-Datenbankinstanz über die Cloud günstiger beziehen kann, fällt dann aber bei der Abrechnung aus allen Wolken, weil die Cloud zum Beispiel mit 36 Oracle-Cores läuft. Dies bedeutet: Der Kunde bezahlt den günstigeren Grundbetrag – aber 36-mal. Hier handelt es sich nicht um versteckte Kosten, sondern viele IT-Verantwortliche und Controller haben sich mit den Cloud-Kostenstrukturen einfach nicht ausreichend beschäftigt. Dazu gehört auch das der Cloud inhärente Prinzip, dass sich die Preisgestaltung monatlich, wöchentlich oder gar täglich neu konfiguriert. Dies führt dazu, dass Rechnungen für viele Kunden nicht mehr nachvollziehbar sind.

Lesen Sie dazu auch: Die besten Tools für das Cloud-Management

Multi Cloud hebt zusätzliche Kostenpotenziale

Das Kostenthema wird noch komplexer, wenn ein Unternehmen Cloud-Brokerage als nächste Evolutionsstufe nach der Cloudifizierung betreibt. Dies ist auch grundsätzlich sinnvoll. Denn wer zwei, drei oder mehrere Clouds nutzt, verhindert die Abhängigkeit von nur einem Anbieter (Lock in). Mehrwerte lassen sich erzielen, wenn es später zum Beispiel darum geht, die anfallenden Datenmengen zu speichern, etwa beim Backup. Wenn das Cloud Readiness Assessment eines Unternehmens ergibt, dass sich Backups grundsätzlich bei Amazon, Google und Microsoft durchführen lassen, dann spricht nichts dagegen, sie je nach Preislage heute hier und morgen dort zu realisieren. Voraussetzung ist, ein intermediäres System über die verschiedenen Cloud-Plattformen hinweg zu schaffen. Dies ist technologisch gesehen keine große Herausforderung. Schwieriger ist es für ein Unternehmen, sich erst einmal an den Gedanken zu gewöhnen, dass sein Backup über verschiedene Standorte hinweg verteilt liegt – etwa in Dublin, Amsterdam, Frankfurt und der Schweiz.

Es geht also häufig um einen kulturellen Wandel, der die Komplexität bewusst steigert und traditionelle Vergabe- und Abrechnungsstrukturen verändert. So ist es zum Beispiel zwingend notwendig, das Kostenmanagement zu automatisieren. Wer hier auf Excel setzt, stößt an Grenzen: Damit lassen sich die Kosten in Multi-Cloud-Umgebungen nicht mehr abbilden und steuern. Das Schwierige dabei: Die Kostenstrukturen der einzelnen Cloud-Anbieter lassen sich nicht miteinander vergleichen. So bieten die Cloud-Provider eigene Tools und Dashboards für das Management an, die untereinander jedoch nicht kompatibel sind. Insofern sind Unternehmen in einer Multi-Cloud-Umgebung auf ein Kostenmanagement-Tool angewiesen, das herstellerunabhängig alle genutzten Clouds abbilden kann. Nur so lassen sich anfallende Workloads übergreifend überwachen oder Verlaufskurven der Cloud-Nutzung anzeigen. Die Automatisierung geht heute schon so weit, dass die Tools beispielsweise nicht oder kaum genutzte Services automatisch kündigen oder herunterfahren.

„Container“ verbinden Cloud-Welten

Damit sich die Kosten für Clouds übergreifend automatisiert managen lassen, sind Standards nötig. Nur so lassen sich die unterschiedlichen Angebote unter einem Clontrolling- und Reporting-Dach vereinen. Das machen heute sogenannte Container-Architekturen möglich. Diese Container sind die nächste Evolutionsstufe nach der Virtual Machine (VM). Eine einzelne VM lässt sich nicht einfach in Microsofts Azure runterfahren und am nächsten Tag bei Amazon wieder hochfahren. Mit Containern hingegen ist dies möglich. Der Vorteil: Die großen Cloud-Anbieter bieten mittlerweile Tools an, die Bestands-Applikationen in Container-Applikationen konvertieren.

Allerdings sind nicht alle Bestandsanwendungen Multi-cloud- und Container-fähig. Dies evaluiert in der Regel das Cloud Readiness-Assessment. Prinzipiell gilt, je weniger „tief“ die Anwendungslogik in der IT-Infrastruktur verankert ist, umso einfacher fällt die Containerisierung aus. Weitere Voraussetzung: eine vollständig implementierte Devops-Toolchain. Deshalb sind es auch weniger kleinere Unternehmen mit nur einem oder wenigen IT-Administratoren, die diesen Prozess erfolgreich durchlaufen können. Es sind vielmehr Großunternehmen, die über die personellen und finanziellen Mittel verfügen, um auch Bestandssysteme an eine Container-ähnliche Architektur heranzuführen.