Drei Fragen und Antworten: Raus aus der Cloud? Und wenn ja, wie?
Die Hyperscaler lassen sich ihre Dienste gut bezahlen und erschweren den Ausstieg, wo es nur geht. Doch sowohl Kostenkontrolle als auch Cloud-Exit sind möglich.
(Bild: iX)
- Ulrich Wolf
Viele Unternehmen bemerken erst zu spät, dass sie für AWS, Azure & Co. oft zu viel bezahlen. Warum das so ist, darüber sprachen wir mit iX-Autor Martin Loschwitz. Er erklärt auch, wie man am besten von vornherein darauf achtet, wieder herauszukommen und nicht für immer beim Hyperscaler gefangen zu sein.
Viele Firmen gehen in die Clouds von Microsoft, AWS und Google. Sie wollen Kosten sparen und stellen dann fest, es wird teurer – oft sehr viel teurer – als gedacht. Woran liegt das und warum weiß man das nicht vorher?
Dafür gibt es etliche Gründe. Zunächst nutzen viele Unternehmen zwar die angebotenen Werkzeuge zur Kostenkalkulation, gehen bei ihren Berechnungen aber von zu wenigen benötigten Ressourcen aus. Schon die gebuchten Ressourcen schlagen oft also mit mehr Geld als erwartet zu Buche – auch, weil in Clouds einzelne Faktoren wie die Nutzung bestimmter Dienste (Load Balancer as a Service, LBaaS) verschiedenste Faktoren verrechnen, das aber über das Portfolio des Anbieters hinweg nicht einheitlich ist. Manche Ressourcenarten verrechnen Traffic, andere beziehen eher die Anzahl von Anfragen über einen bestimmten Zeitraum ein. Wer nicht viel Erfahrung hat, vergisst also oft einzelne Posten und erlebt dann ein böses Erwachen.
Deutlich unterschätzt wird zudem die Arbeit, die regelmäßig nötig ist, um bestehende Set-ups in der Umgebung lauffähig zu halten, nachdem der Anbieter Änderungen vorgenommen hat. Einige Unternehmen verlassen sogar die Cloud wieder, weil umfangreiche CI/CD-Pipelines so viele laufende Kosten verursachen, dass der Betrieb auf eigener Hardware mit weniger Automation billiger wäre. Auch dieser Faktor ist im Vorfeld aber nur sehr schwer zu kalkulieren. Und je nach seiner Höhe stellt man dann möglicherweise sogar fest, dass die gesamte Kalkulation für den Ausflug in die Cloud hinfällig ist.
Warum wird ist es oft so aufwendig und kostspielig, den Anbieter zu wechseln oder wieder ganz oder teilweise auf eigene Infrastrukturen zu gehen?
Jeder Hyperscaler hat ein Interesse daran, Kunden auf der eigenen Plattform zu behalten. Deshalb hantieren AWS & Co. mit klassischen Lock-in-Effekten. AWS CloudFormation, AWS EKS, die enthaltenen Monitoring-Werkzeuge und viele weitere Komponenten sind hochspezifisch für Amazon AWS konzipiert. Azure und Google machen das auch nicht anders. Das Problem ist also: Sind die eigenen Prozesse etwa auf AWS hin optimiert, käme der Wechsel zu einem anderen Anbieter regelmäßig einem weitgehenden Rewrite des Lifecycle-Managements der eigenen Anwendung gleich. On Premises steht zudem oft gar keine Cloud zur Verfügung, die Dienste wie LBaaS anbieten kann. Die entsprechenden Dienste sind dann durch eigene Werkzeuge zu ersetzen, was auch wieder Entwicklungsressourcen verschlingt.
Neben den Titelthema Cloud-Kosten und Cloud-Exit geht es in der neuen iX darum, was 2024 an mit NIS2, Cyber Resilience Act und anderen Richtlinien an Regulierung auf uns zukommt. Was das Energieeffizienzgesetz für RZs bedeutet, zeigt ein eigener Artikel. Außerdem: Wie finde ich die beste Storage-Option für Kubernetes, wie sicher sind biometrische FIDO-Token, die funktionale Sprache Elm als Javascript-Ersatz und vieles mehr. Ein Überblick über alle Themen findet sich hier.
Welche Techniken sollten Unternehmen am besten einsetzen, damit der Ausstieg gelingt?
Ganz generell hilft es, wenn man bereits bei der Entwicklung eigener CI/CD-Umgebungen darauf achtet, generische Werkzeuge wie Terraform zu nutzen. Diese bieten eine interne Abstraktion, sodass der Admin etwa nur festlegen muss, dass ein Loadbalancer zu starten ist. Auf AWS, Azure oder GCP nutzt das Werkzeug dann die jeweils angebotene Ressource der Plattform. Damit lassen sich bereits einige Probleme umgehen – etwa auch das zuvor schon beschriebene Problem, die eigene Automation auf Stand mit der Plattform zu halten. Denn im günstigsten Falle genügt es in einer solchen Situation, das Deployment-Werkzeug, etwa Terraform, auf eine neue Version zu heben, die mit den veränderten Anforderungen der Cloud zurechtkommt.
Ansonsten gelten die üblichen Hinweise: Je generischer eine Umgebung konzipiert ist, desto größer ist die Wahrscheinlichkeit, dass sie gut von einer Plattform in eine andere Umgebung zu verschieben ist. Dann lässt sich mit wenigen Handgriffen ein PoC-Setup in einer anderen Umgebung etablieren, bei dem bloß noch die Daten zu migrieren sind. Wer hier eine gängige Datenbank nutzt, macht sich ebenfalls das Leben leichter. Kommt hüben wie drüben etwa MySQL zum Einsatz, ist die Migration mit Werkzeugen wie mysqldump gut schaffbar.
Herr Loschwitz, vielen Dank für die Antworten! Ausführliche Beiträge zu den Kostenfallen in der Cloud, Cloud-Exit-Planung, souveränen Cloud-Anbietern als Alternative zu den Hyperscalern und ein detailliertes Interview zum Cloud-Ausstieg des SaaS-Anbieters 37signals finden Sie in der aktuellen iX, die ab heute im heise Shop und am Kiosk erhältlich ist.
In der Serie "Drei Fragen und Antworten" will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.
(ulw)
