Abhängigkeiten vermeiden, Flexibilität bewahren DBaaS erleichtert die Cloud-Migration

Anbieter zum Thema

Couchbase Germany GmbH

Rittal GmbH & Co. KG

DAXTEN GmbH

Kentix GmbH

Die Ablösung von On-Premises-Architekturen durch Cloud Computing ist in vollem Gange – und macht natürlich vor den Datenbanken nicht halt. Wenn die Cloud-Migration ansteht, sind sie allerdings ein entscheidender Faktor für das Gelingen.

Der Erfolg von Cloud Computing hat viele Gründe: Auf der technischen Seite sind das vor allem die bessere Verfügbarkeit der IT-Ressourcen, die höhere Flexibilität und Skalierbarkeit. Unter Kostenaspekten fällt besonders der zumindest teilweise Verzicht auf eigene teure Rechenzentrums-Investitionen positiv ins Gewicht sowie die Möglichkeit, die Cloud-Ausgaben als steuermindernde operative Kosten (OpEx) abrechnen zu können. Allerdings warten bei der Cloud-Migration eine ganze Reihe von Hürden und Fallstricke auf den, der diese Vorteile praktisch nutzen möchte.

Einer der wichtigsten Punkte auf der Migrations-Agenda ist der Transfer der bislang intern gehosteten Daten in die Cloud. Allein dieser Schritt kann sich, je nach Art und Umfang der zu transferierenden Datenbestände, zu einem zeit- und kostenintensiven, oft genug auch nervenzehrenden Projekt auswachsen.

Als Alternative zum tage-, wenn nicht wochenlangen Überspielen großer Datenvolumen über Netze bieten einige Hyperscaler daher den Datentransfer per LKW an. Amazon beispielsweise stellt auf der „Ladefläche“ (!) seiner Snowmobile-Trucks bis zu 100 Petabyte, also 1.000 TByte an Speicherkapazität bereit, die anschließend per Schutzeskorte über den Highway zum Cloud-Datacenter kutschiert werden. Da bekommt der abgegriffene Begriff „Datenautobahn“ eine ganz neue, merkwürdig anmutende Bedeutung. Aber selbst über eine 10-Gbit-Leitung dauert das Laden eines solchen automobilen Datenspeichers bis zu zehn Tage. Allerdings entfallen die normalerweise beim Cloud-Provider anfallenden Transferkosten.

Wohin mit den Daten?

Bevor die Daten endlich in der Cloud ankommen, stellt sich natürlich vorab die Frage nach der Datenbank, in der sie gespeichert werden sollen. Grundsätzlich haben Cloud-Nutzer die Wahl zwischen der Cloud-Datenbank eines Hyperscalers, einer traditionellen SQL- oder einer cloud-nativen NoSQL-Datenbank. Hilfreich bei der Entscheidung ist dabei die Analyse der Stärken und Schwächen des jeweiligen Datenbank-Typs in der Cloud, in Bezug auf die eigenen Zwänge und Ansprüche.

Auf den ersten Blick scheint es logisch und sinnvoll, die nativen Datenbank-Angebote der Public-Cloud-Anbieter zu nutzen. Nutzer laufen dabei jedoch Gefahr, in eine von zwei ganz unterschiedlich geartete Fallen zu tappen. Der erste Fall bezieht sich auf den häufigen Fall einer Cloud-Monokultur, wenn sie bei nur einem Hyperscaler andocken. Nicht nur die Nutzung der internen Cloud-Datenbank erhöht die Abhängigkeit, die hauseigenen Datenbank-Services sind auch ganz speziell auf die internen Cloud-Angebote ausgelegt. Da ist es bis zum gefürchteten Vendor-Lockin nicht mehr weit.

Schon allein aus diesen Gründen sollte eine andere Lösung gewählt werden. Die typischerweise undurchsichtigen, kalkulationsfeindlichen Preismodelle tun ein Übriges. Und die zweite Einschränkung bezieht sich auf die immer beliebtere, weil sinnvolle Nutzung von Hybrid- oder Multi-Cloud-Architekturen. Da verbietet sich die Nutzung einer Hyperscaler-spezifischen Cloud-Datenbank quasi von selbst. Sowohl Cloud-, als auch Provider-Agnostik sollten deshalb zum selbstverständlichen Datenbank-Repertoire bei der Cloud-Migration gehören.

Cloud-native Datenbanken für die Cloud Migration

Bleibt also die Frage, ob SQL oder NoSQL. Die eingangs angesprochenen Vorteile von Cloud Computing wie Skalierbarkeit, Verfügbarkeit oder Flexibilität sollten sich auch in dem dafür eingesetzten Datenbank-Management-System widerspiegeln. Andernfalls würden viele davon wieder verschenkt. Relationale SQL-Datenbanken arbeiten typischerweise mit einer starren Zeilen/Spalten-Matrix. Nachträgliche Änderungen sind nur mit großem Aufwand und hoher Fehleranfälligkeit möglich. Und sie sind immer Anbieter-spezifisch, mit hohem Aufwand und der Gefahr entsprechender Abhängigkeiten verbunden. In agilen, verteilten Cloud-Umgebungen mit ihren virtuellen Maschinen und Kubernetes-gesteuerten Microservices kann das nicht die ideale Lösung sein.

NoSQL-Datenbanken sind von ihrer prinzipiellen Architektur her besser für Cloud-Umgebungen geeignet. Sie sind per se Cloud-native, hochskalierbar, latenztoleranter und ausfallsicherer. Dabei darf jedoch nicht übersehen werden, dass es riesige Unterschiede bei der Cloud-Qualifikation gibt, etwa bei den Replikations-Fähigkeiten oder den Automatisierungsfunktionen. Hohe Automatisierungslevel unterstützen Cloud-Migration und -Betrieb mit autonomen Services wie Automated Provisioning, Auto Failover, Auto Scheduling, Centralized Management, Failure Recovery oder vertikalem und horizontalem On-demand Dynamic Scaling.

Für die Cloud besonders interessant ist die Cross-Datacenter-Replikation (XDCR). Per XDCR kann beispielsweise die On-premisses-Datenbank in die Cloud repliziert werden. Nach der anschließenden Synchronisation ist sie dann in den Applikationen verfügbar – und die Migration erfolgreich vollzogen. Während der Migration selbst kann sie zudem dafür genutzt werden, vorsorglich ein temporäres Backup auf eigenen Servern zu fahren.

Warum DBaas?

Database-as-a-Service (DbaaS) stellt diese Funktionalitäten wie einen Streaming-Dienst per Flatrate bereit. Analog zu Audio- und Video-Diensten, die Plattenspieler, CD-Player und Videorekorder überflüssig machen, entfällt bei DbaaS die Notwendigkeit, eine eigene Datenbank-Infrastruktur installieren, steuern und warten zu müssen. Abgesehen von den Kosten- und Bereitstellungsvorteilen (Flexibilität, Skalierbarkeit) übernimmt der DBaaS-Provider auch Maintenance, Updates und Upgrades als Managed Service. Das entfällt damit für den Scope-of-work eines Datenbank-Administrators, inklusive quälender Nachtschichten für geschäftskritische 24x7-Anwendungen.

Ein Punkt sollte bei der Cloud-Migration auf keinen Fall vergessen werden: Der Plan B für Fallback und Disaster Recovery zur Risikominimierung. Es wäre nicht das erste Mal, dass es beim Schritt in die Cloud zu Stolperern, wenn nicht gar Stürzen kommt. Die Synchronisation per XDCR ist ja bereits genannt worden. Die Vorbereitung für ein Worst Case Szenario ist deshalb kein defätistischer Ansatz, sondern gute Prophylaxe für einen hoffentlich nicht eintretenden Ernstfall. Auch dabei kann DBaaS hilfreich sein, weil er unabhängig von der gerade aktiven, respektive inaktiven eigenen IT-Infrastruktur verfügbar ist. Wer seine Daten damit in dislozierte Speicher für Backup, Archivierung und Disaster Recovery repliziert hat, reduziert das Crash-Potenzial bei der Cloud-Migration. Durch DBaaS werden also sowohl die Datenbank-Funktionen, als auch die Daten selbst resilienter.

(ID:49835648)