Nach der Pandemie ist vor der Datenbank-SystemumstellungKomplexer als gedacht – neue Wege sind gefragt

Strukturierte Datenbanken (NoSQL-Datenbanken) bieten fraglos einen hohen Nutzwert. Doch es gibt wichtige Bereiche der Unternehmens-IT, für die sich ihr Einsatz nicht wirklich aufdrängt. Das gilt vor allem für transaktionale Anwendungen.

Gegenwärtig 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.

Es dürfte allgemein bekannt sein, dass es bei der ersten Generation der Cloud-Migration darum ging, CapEx in OpEx zu verwandeln, 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 Konzept „Lift and Shift“ ist von Natur aus riskant, 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 Anwendungs-Virtualisierung, 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

Das Problem ist, 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 dieser Problematik 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 ist der Auffassung zuzustimmen, dass die NoSQL-Revolution es möglich gemacht hat, 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 Wartungs-Upgrades 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 ernstzunehmendem 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 Potential 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 ist Field CTO für die Region EMEA bei Yugabyte.

Yugabyte