Umzug in die Cloud Nach der Pandemie ist vor der Datenbank-Systemumstellung

Ein Gastbeitrag von David Walker*

Strukturierte Datenbanken haben zweifellos einen hohen Nutzwert. Doch es gibt wichtige Bereiche der Unternehmens-IT, bei denen ihr Einsatz nicht wirklich naheliegt. Das gilt vor allem für transaktionale Anwendungen.

Anbieter zum Thema

Um das Potenzial der Cloud sinnvoll nutzen zu können, müssen Unternehmen ihre Systeme auf diese nächste Stufe bringen.
Um das Potenzial der Cloud sinnvoll nutzen zu können, müssen Unternehmen ihre Systeme auf diese nächste Stufe bringen.
(Bild: gemeinfrei / Pixabay )

Im Moment wagen sich Unternehmen mit Online-Stores Schritt für Schritt aus dem langen Schatten der Pandemie heraus. Die Weltbank geht davon aus, dass sich die Weltwirtschaft so schnell von der Rezession erholen wird, wie das seit 80 Jahren nicht mehr der Fall war.

Allerdings hat die globale Gesundheitskrise die Geschäftswelt möglicherweise für immer verändert. Zur Disposition steht weit mehr als nur die Frage, ob wir wieder Vollzeit ins Büro gehen werden. Im Zuge der digitalen Transformation hat während der Pandemie ein grundlegender und unumkehrbarer Wandel hin zur verstärkten Nutzung digitaler Technologien eingesetzt und seitdem noch deutlich an Schwung gewonnen. Die Unternehmensberater von McKinsey berichten, dass bei vielen Unternehmen digitale Projekte, die für die nächsten sieben Jahre geplant waren, jetzt innerhalb weniger Monate durchgeführt wurden.

Ausgetretene Pfade führen nicht mehr zum Ziel

Im Zusammenspiel zwischen Marktentwicklung, Anwendungsdynamik und Profitabilität ist der CIO der entscheidende Akteur, der die Cloud immer intensiver nutzt: In vielerlei Hinsicht geht es bei der digitalen Transformation darum, den Kunden Rechenleistung und in hohem Maße auch Dienstleistungen über die Cloud zur Verfügung zu stellen. Bei näherer Betrachtung zeigt sich allerdings: Die Angelegenheit ist komplexer als gedacht. Die Entscheidungen und Entwicklungen, welche die Unternehmen zum Status quo gebracht haben, sind nicht notwendigerweise auch für die Zukunft tauglich. Wollen wir die Cloud nutzen, um die nächste Stufe der digitalen Wirtschaft zu erreichen, müssen wir uns mit einigen Einsichten und Wahrheiten über die Art und Weise auseinandersetzen, wie das Business im Cyberspace heute üblicherweise läuft – und wie es laufen sollte.

Bei der ersten Generation der Cloud-Migration ging es darum, CapEx in OpEx zu verwandeln, also der Transformation von Investitionskosten in Betriebskosten. Das funktionierte sehr gut, aber schon bald mussten zahlreiche Akteure feststellen, dass sich eine große IBM- oder Oracle-Datenbank nicht einfach in die Cloud verlagern lässt. Das Rehosting ist von Natur aus riskant und bei großen monolithischen Anwendungen technisch schlicht nicht machbar.

Die erste Generation der Cloud-Ingenieure in Unternehmen hat versucht, diese großen Systeme in viele kleine Teile zu zerlegen und so das Konzept der Virtualisierung entwickelt: Alles, was möglich war, wurde auf nicht-lokale Server in Rechenzentren verschoben. Aus der gleichen Ausgangslage entstand das Konzept der Containerisierung - die Idee, dass man nicht jede Software auf einem Betriebssystem auf einem virtuellen Server auf einem Stück Metall installieren muss, sondern sie in einen Container packen kann. Das wurde zunächst mittels virtueller Maschinen (VMs) realisiert, schon bald aber mit Dockern – jener Form der Anwendungsvirtualisierung, der man besonders benutzerfreundliche Eigenschaften nachsagt und die den Begriff des Containers als Alternative zu virtuellen Maschinen populär machte. Die meisten Anwender befinden sich wahrscheinlich gegenwärtig an genau diesem Punkt. Sie verwenden Technologien wie Kubernetes, um viele orchestrierte Container miteinander zu verbinden. Die meisten User sind inzwischen auch mehr oder weniger überzeugte Anwender agiler Techniken. Damit bedienen sie sich eines mächtigen Hebels, um die damit verbundene Komplexität zügig in den Griff zu bekommen.

NoSQL war ein großer Fortschritt, aber er bringt die Anwender nicht ganz über die Ziellinie

Ein Hindernis besteht darin, dass die Probleme auf der Datenbankseite nie wirklich gelöst wurden. Wenn man in die Cloud geht und darauf hofft, dass der Service für jeden zu jeder Zeit, an jedem Ort und auf jedem Gerät verfügbar ist, muss die Datenbank zwingend jederzeit verfügbar sein. Kein Anwender kann es sich leisten, dass sie ausfällt. Auch vorbeugende Wartung ist zu vermeiden, und lange Upgrade-Zyklen sind nicht gut für die Online-CX. Die Lösung dafür besteht im Einsatz verteilter NoSQL-Datenbanken: Solche Datenbanken lassen sich auf Hunderten von Knoten in der Cloud bereitstellen, man kann sie auf verschiedene Regionen verteilen und sie bieten ihren Nutzern ein erhebliches Maß an Ausfallsicherheit.

Vor diesem Hintergrund hat die NoSQL-Revolution es tatsächlich möglich gemacht, die traditionellen monolithischen Datenbanken in der Cloud nutzbar zu machen. Allerdings wird dabei unter einem wichtigen Aspekt das Kind mit dem Bade ausgeschüttet: Mit NoSQL-Datenbanken lassen sich keine Transaktionen durchführen. Es war daher ein genialer Schachzug, die Datenbank in kleinere Einheiten in Form von Microservices aufzuteilen. Jedes dieser Pakete verfügt über eine eigene Datenbank. Allerdings ist für diesen Ansatz regelmäßig eine große Anzahl von NoSQL-Datenbanken erforderlich.

Warum ist das ein Problem? Wenn ein Kunde etwas online kauft oder Geld von A nach B transferiert, gibt es zu einem unterbrechungsfreien, zuverlässigen Funktionieren des Systems an allen involvierten Orten keine Alternative. Wenn ein Kunde etwas in seinen Online-Einkaufskorb legt und es geht durch einen IT-Fehler verloren, ist das zwar ärgerlich, aber keine echte Katastrophe. Geht es dagegen um Bezahlvorgänge und Überweisungen, so muss das System einfach funktionieren und die beteiligten Konten sofort ausgleichen. Diese Fähigkeit konnte bei Transaktionssystemen als selbstverständlich vorausgesetzt werden - bis die Cloud-Revolution begann: Dann mussten Anwender anfangen, enorme Mengen an zusätzlichem Code zu schreiben – Tausende von Codezeilen mit all der Komplexität, den Wartungsupgrades der Anbieter und den Kosten. Das ist bitter, denn vor zehn Jahren erledigte eine einzige Zeile SQL-Code die Aufgabe in perfekter Weise.

Echte Mainframe-Transaktionen in der Cloud

Der Aufruf zum Handeln lautet hier, dass es in dem Maße, in dem Unternehmen immer mehr Post-Covid-Geschäfte mit digitaler Geschwindigkeit abwickeln wollen, es auch immer mehr Anwendungsfälle geben wird, die sie nicht allein mit einem virtualisierten Microservices- und NoSQL-Ansatz bewältigen können. Leider ist es auch nicht möglich, zu den großen alten Oracle- und IBM-Lösungen zurückzukehren.

Als E-Commerce-Anbieter mit ernst zu nehmendem Geschäftsumfang kann man sich nicht durch das Schreiben zusätzlichen Programmcodes aus dieser Situation befreien. Das wäre mit enormen Kosten verbunden, aber auch mit größerem Risiko und höherem Zeitaufwand. Die Lösung muss daher ein verteilter, transaktionaler Low-Code-Cloud-Datenansatz sein. Dieser kann jenes eine Puzzlestück liefern, das NoSQL nicht liefern konnte: einfache, zuverlässige, sofortige und skalierbare Transaktionsunterstützung.

So schmerzlich diese Erkenntnis für Anwender sein mag, die bereits während der Pandemie die digitale Transformation ihrer Marke unter hohem Arbeitsaufwand vorantrieben: Um das Potenzial der Cloud sinnvoll nutzen zu können, müssen sie ihre Systeme auf diese nächste Stufe bringen. Dieser Schritt ist unabdingbar, um die gleiche Leistung und Zuverlässigkeit zu erhalten, die relationale Datenbanken früher boten – das alles aber in der Betriebsumgebung von heute: der Cloud.

* David Walker arbeitet als Field CTO, EMEA bei Yugabyte.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

(ID:47995676)