Kunden verabschieden sich (teilweise) von der Cloud

on

Dieser Artikel ist als DOAG Datenbank Kolumne am Mo, 14. September 2026 veröffentlich worden.

Was sind die Gründe, warum sich Firmen wieder aus der Cloud verabschieden? Wo liegen die Vor- und Nachteile der Cloud? Wo macht eine Verlagerung in die Cloud Sinn und wo nicht?

Die Hoffnung vieler Kunden, dass man durch den Schritt in die Cloud Kosten – und hier auch Personal – einsparen kann, hat sich bei vielen Unternehmen nicht verwirklicht. Immer öfter liest man in den Medien, dass sich große Unternehmen aus der Cloud verabschieden – beispielsweise: Kosten meist höher als gedacht: Kunden verabschieden sich (teils) von der Cloud. Auch Gartner und Unternehmen haben schon mehrfach betont, dass der Weg in die Cloud nicht günstiger sein muss, als on-Premise (siehe auch Cloud kann teuer werden). Gehen wir einen Schritt zurück und schauen uns die Gründe für den Schritt in die Cloud an.

Einsparungen

Gerade am Anfang, als AWS (fast) noch allein mit dem Cloud Business begonnen hat, war das Versprechen „In der Cloud wird alles günstiger und einfacher!“ oft die Entscheidungsgrundlage für Manager, diesen Weg zu gehen. Wir haben bei einem internationalen Kunden ein vom Management getriebenes Projekt „Unsere IT muss komplett in die Cloud“ 2016/2017 analysierend begleitet und unsere Erkenntnisse unter anderem am DB Masters Event 2018 im Vortrag Von Äpfel und Birnen – Cloud Anbieteraussagen versus on-Premise geteilt. Der Kunde hat damals sein SAP DWH als POC in die AWS Cloud kopiert und dabei Folgendes festgestellt: Um die Workload überhaupt laufen lassen zu können, mussten mehr als doppelt so viele CPUs provisioniert werden, als on-Premise im Einsatz waren. Die Laufzeit aller Verarbeitungen war im Schnitt um einen Faktor über 3 langsamer. Die Kosten waren zu diesem Zeitpunkt (im POC wurde ein kompletter Monat in der AWS Cloud betrieben und dann die Kosten mit on-Premise verglichen) um einen Faktor von über 4 höher.

Das Teilprojekt „Migration der (nicht nur Oracle-) Datenbanken in die Cloud“ wurde daraufhin eingestellt. Fun Fact: Der Kunde hat wirklich einen Teil seiner IT in die Cloud verlegt (nicht jedoch die Oracle-Datenbanken) und die IT-Kosten haben sich dadurch verdoppelt. Daraufhin wurde ein Teil wieder zurückgeholt, um die IT-Budgets wieder einhalten zu können.

Selbstverständlich kann man in der Cloud auch Kosten sparen, allerdings nicht, wenn man eine fixe, permanente Workload wie stark ausgelastete Datenbanken nutzt. Damit man Kostenreduktion erfährt, braucht man massiv schwankende Lasten, wo man gezielt VMs bei Bedarf ein- und ausschaltet.  Bei einem anderen Kunden von uns, der kundenprojektbezogen starke Schwankungen in der Rechenleistung (und der benötigten Internetbandbreite) hat, war der Schritt in die Cloud ein massiver Kostenvorteil. In der Applikation wird eine Art „Marktvergleich“ durchgeführt, indem man mit spezialisierten Agents nach bestimmten Kriterien im Internet nach Daten sucht und diese dann automatisiert analysiert. Es gibt Projekte, die für einige Tage laufen und danach abgeschlossen sind. Andere Projekte laufen in regelmäßigen Intervallen (monatlich, saisonal oder auch nur jährlich). Kleine Projekte benötigen nur einen Agent, andere gerne mal ein Duzend gleichzeitig. Vor der Cloud wurden dafür duzende Server im eigenen Rechenzentrum betrieben, die für Auftragspeaks ausgelegt werden mussten. In der Cloud wird einfach – automatisiert – die benötigte Anzahl von Agents gestartet und danach wieder gestoppt. Die durchschnittliche Auslastung der on-Premise-Server für die Agents lag bei unter 10%. Der Schritt in die Cloud hat nicht nur Kosten bei der Infrastruktur eingespart, sondern auch das Problem mit der Bandbreite der Internetanbindung gelöst.

Ja, Einsparungen sind durchaus möglich, es hängt aber von den Anforderungen ab. 

Reduktion der Komplexität

Gleich vorweg, wir selbst nutzen zwar Cloud Services wie Office365 und andere Anbieter – wir betreiben aber keine eigenen Systeme (PAAS, IAAS, …) in der Cloud. Allerdings unterstützen wir unsere Kunden auch für Datenbanken, die diese in den verschiedenen Clouds (aktuell AWS, Azur und Oracle) betreiben. Spricht man mit den „ehemaligen“ DBAs, so hat sich ihr Job massiv geändert. Der Anteil an „produktiver“ Tätigkeit ist deutlich zurück gegangen – und das gilt im speziellen für deren Kollegen im Infrastrukturbereich (Server, Storage, Netzwerk). Es wird sehr viel Zeit auf Grund der Komplexität und aufwändigen Cloud-Administration verbraucht. Möchte man sich auf einen bestimmten Rechner anmelden, so kann das schon 5 Minuten (oder noch länger) dauern. Gemessen ab dem Start der Client Software (beispielsweise Amazon Workspaces),  über die verschiedenen Anmeldungen auf den unterschiedlichen Systemen, dauert es eine Ewigkeit bis man auf den Datenbankrechner zugreifen kann. 

Die Hoffnung vieler Manager, dass man weniger Personal benötigt, wenn man in die Cloud geht, stimmt in der Regel nicht. Im Gegenteil, es werden oft zusätzliche Mitarbeiter benötigt, die sich um verschiedene Aspekte im Umgang mit der Cloud ZUSÄTZLICH kümmern müssen. Auch wenn eine Datenbank und/oder ein Service in der Cloud läuft, muss es noch administriert und optimiert werden – und das ist in der Cloud oft deutlich komplexer. Ja, einige Tätigkeiten wie Patching muss jetzt nicht mehr der DBA machen, aber gemacht werden muss es trotzdem. In einem Kundenprojekt sind für jedes Patching einer Oracle-Datenbank in der Cloud ca. 5-6 Personen beschäftigt. Es beginnt mit einem zusätzlichen Backup der Datenbank (durch den DBA), dann wird ein Snapshot des Betriebssystems und der Oracle-Software erstellt (durch einen Server Admin). Das Initieren des Patchings erfolgt über einen Cloud Admin (die DBAs dürfen dies selbst nicht machen). Nach dem Patching müssen Applikations-Services (vom Applikations Admin) restartet und die Anwendung (von einem Benutzer) geprüft werden. Zuletzt sind nochmals die DBAs dran, die Nacharbeiten durchführen. Als das System noch on-Premise gelaufen ist, waren nur zwei Personen beschäftigt: Die DBAs haben alles, außer das Testen der Applikation nach dem Upgrade, allein gemacht – und das auch noch in einem Bruchteil der Zeit im Vergleich mit dem Patching in der Cloud.

Flexibilität und Skalierbarkeit

Ja, in der Cloud ist man flexibel. Man kann neue Systeme deployen und nicht mehr benötigte stilllegen bzw. löschen – idealerweise gleich noch automatisiert.

Wunderbar und perfekt, wenn man das auch wirklich benötigt – beispielsweise im Entwicklungsbereich. Für den Betrieb von Datenbanken, die oft viele Jahrzehnte genutzt werden, bringt diese Flexibilität nichts! Wie das Beispiel bei den Einsparungen (das mit den Agents) schon aufgezeigt hat, kann man diese Flexibilität mit Hilfe der richten Konfigurationen und Tools auch wirklich nutzen. Der Weg dahin ist aber mitunter steinig und oft nur durch Unterstützung von Consultants zu lösen.

Bessere Performance

Aus der Erfahrung von vielen duzend Projekten ist ganz klar zu sagen: Das kommt massiv darauf an, von wo man startet.

Nutzt man noch sehr alte (wir haben in Projekten geholfen, Server aus dem letzten Jahrtausend mit Cloud abzulösen) und entsprechend langsame Systeme, so kann es mit der Cloud wirklich schneller und besser werden. Das gilt auch dann, wenn man in die Jahre gekommene interne Virtualisierungslösungen (VMware oder HyperV), die womöglich noch mit Harddisk-basierten Storages arbeiten, ablöst oder das interne RZ-LAN noch mit 100MBit betreibt. Versucht man jedoch von einer einigermaßen aktuellen (maximal 2-3 Jahre alt, nur SSD/NVMe in Server und Storage, mindestens 10 GBit/s LAN bzw 16GBit SAN), sinnvollen (richtige CPU für den Anwendungsfall), nicht überprovisionierten on-Premise- Lösung in die Cloud zu wechseln, wird man negativ überrascht.

Vor Kurzem wurden wir von einem Neukunden kontaktiert, der sich die schlechte Performance der Datenbanken in der Cloud nicht erklären konnte. Um es reproduzierbar zu machen, hat der Kunde eine Test-Datenbank on-Premise aufgesetzt und dann in die Cloud kopiert und anschließen das Tool Oracle SLOB genutzt, um Last zu erzeugen. Das Ergebnis auf der „alten“ on-Premise-Infrastruktur war um ein Vielfaches besser. Da sich das niemand erklären konnte, wurden wir kontaktiert. 

Nach einer Adjustierung einiger Instance Parameter und einem Test mit Oracle I/O Calibrate war klar, dass es sich um ein I/O Problem handelt, da die CPU lediglich mit einem Core ausgelastet war. Einige Nachforschungen später war die Erklärung, dass es an der IOPS-Limitierung (Abhängig von verschiedenen Faktoren) liegt. Der Cloudanbieter limitiert bei der gebuchten Konfiguration auf 16.000 4k IOPS. Da die Oracle Blocksize 8k ist, und neben der Datenbank auch jeglicher I/O auf das Filesystem (Logfiles, Tracefiles, …) mitgerechnet wird, ist nach ca. 7.500 IOPS aus Datenbanksicht Schluss.

Für den Betrieb (verifiziert auf der on-Premise Datenbank) sind zwischen 4.000 und 5.000 IOPS notwendig – es ist zwar knapp, geht sich aber aus. Während des RMAN-Backups (das sehr lange läuft) ist die Applikation aber merklich langsamer (weil die IO-Latenz ansteigt). Der Kunde hat jetzt die Wahl zwischen Applikationstuning oder Aufzahlen, um mehr IOPS machen zu dürfen. Da dies bei dem Anbieter in der gewählten Konfiguration nur in Kombination mit mehr Cores/Memory möglich ist, müssten auch noch weitere Oracle Datenbank-Lizenzen angeschafft werden.

Lösen von Infrastrukturproblemen

Einige Unternehmen sehen in der Cloud eine Möglichkeit, die internen Infrastrukturprobleme zu „lösen“. Dies ist zwar grundsätzlich bei den meisten Cloud-Anbietern möglich, nur lassen sie sich das auch entsprechend bezahlen – siehe Beispiel „Bessere Performance“. Der Grund dafür ist meist nicht technischer Art, sondern liegt im Management bzw. ist ein menschliches Thema. Speziell bei großen Unternehmen gibt es oft „Silodenken“ – da reden die verschiedenen Abteilungen „Netzwerk“, „Server“, „Storage“, „Datenbank“, „Applikation“, etc. nicht miteinander, sondern schauen nur auf ihren Bereich und versuchen Probleme mit den Möglichkeiten des eigenen Bereichs zu lösen.

Vernünftiger wäre es, sich zusammen zu setzen und die Herausforderungen und Anforderungen zu besprechen und eine Lösung zu erarbeitet, um eine optimale Gesamtlösung zu finden. Das geht auch oft mit „das war schon immer so/das haben wir schon immer so gemacht“, Hersteller- oder Technologievorlieben, aber auch mit Unwissenheit über die aktuell verfügbaren Technologien einher. Hier kann ein externer Berater, der keine Infrastruktur anbietet oder empfiehlt helfen, um einerseits die Anforderungen so zu erheben und zu definieren, dass alle beteiligten verstehen worum es geht und andererseits auch Technologien vorstellen, die helfen diese Anforderungen optimal zu lösen. In Summe ist es über mehrere Jahre meist günstiger, wenn man (fast) alles neu kauft und im eigenen Rechenzentrum umsetzt, als alles aus der Cloud zu beziehen.

Sicherheit und Verfügbarkeit

In der Cloud ist ja alles viel sicherer und immer verfügbar! Die Frage ist dann, warum gibt es so viele Anbieter von Workshops und Schulungen, die sich um das Thema „Wie bekomme ich meine Cloud sicher?“ drehen? Auch das Thema Verfügbarkeit ist so eine Sache – und da braucht man nicht nur an Auswirkungen von Cloudstrike im Sommer 2024 denken, wo viele Verkehrsmittel (Flugzeuge, aber auch Züge und öffentliche Verkehrsmittel) plötzlich ausgefallen sind, nur weil ein fehlerhaftes Crowdstrike-Update Millionen von Windows-Rechner ausfallen hat lassen. Da gibt es noch andere Themen wie gestohlene Masterkeys oder große Ausfälle bei Cloud-Providern aus den verschiedensten Gründen. Suchen sie einfach nach dem Begriff „Cloud-Ausfall“. Da findet man Vieles und bei allen Anbietern.

Wessen sich viele nicht bewusst sind, beispielsweise die Nutzer von Office365, ist dass die Cloud-Service-Anbieter oft kein Backup inkludieren. Man ist für die Sicherung seiner Daten selbst verantwortlich! Würden durch einen Fehler im Office365 Emails gelöscht oder verloren gehen, so verweist Microsoft darauf, dass man für Backups selbst verantwortlich ist. Nachdem aktuelle Versionen der Outlook Clients keine lokalen Emails unterstützen, muss man eine Backup-Lösung anschaffen und betreiben, wenn man seine Emails nicht einzeln abspeichern möchte.

Zusammenfassung

Auch für Cloud gilt: „One Size Fits All“ stimmt definitiv nicht. Viele der Cloud-Versprechen treffen nur unter definierten Rahmenbedingungen zu. Man sollte daher schon im Vorfeld genau überlegen: “Was sind die Gründe, warum ich in die Cloud will?” und „Welche Alternativen gibt es dazu?“. Speziell permanent ausgelastete Datenbanken sind definitiv nicht dafür geeignet um sich in Cloud-Lösungen Geld zu sparen. Sehr dynamische Lasten hingegen können – richtig genutzt – oft kostengünstiger in der Cloud abgebildet werden.

Referenzen