© pixelvario / 123RF.com

Cloud-Datenbanken erfreuen sich wachsender Beliebtheit und steigender Nachfrage. Das liegt nicht nur an höherer Skalierbarkeit und besserer Verfügbarkeit, sondern auch an geringeren Investitions- und Betriebskosten. Allerdings gibt es auch Einschränkungen.

Was eine Cloud-Datenbank überhaupt ausmacht, darüber kann man geteilter Meinung sein. Die Ansichten gehen in zwei Richtungen: Die erste Definition sieht darin Datenbanken, die die Hyperscaler wie Amazon, Azure und Google als Database-as-a-Service (DBaaS) anbieten. Die andere, verbreitetere Meinung bezeichnet damit alle Datenbanken, die jemand innerhalb einer beliebigen Cloud-Infrastruktur bereitstellt, egal ob Private Cloud, Public Cloud, Hybrid/Multi-Cloud oder gehostet als DBaaS. Es geht also lediglich darum, wo die Daten gespeichert sind und wie sich der Zugriff darauf gestaltet. Bei On-premises-Datenbanken erfolgt er über das Unternehmensnetzwerk und gegebenenfalls VPN auf interne Datenbank-Server, bei Cloud-Datenbanken per Internet-Verbindungen auf externe (manchmal auch interne) Cloud-Server.

Bereitstellungsmodelle

Generell sind für Cloud-Datenbanken drei Bereitstellungsmodelle gängig: Die Cloud-Datenbank wird im ersten Fall in Eigenregie betrieben, entweder in der eigenen Datenwolke oder einer Public Cloud. Im zweiten Fall stellt sie ein Hoster als DBaaS bereit. In der dritten Variante konsumiert der Anwender sie als Managed Service.

Im ersten Szenario läuft die Cloud-Datenbank in einer internen oder externen virtuellen Maschine (VM), den Betrieb erledigt aber in jedem Fall die eigene DB-Administration. Bei DBaaS dagegen übernimmt der Hoster oder Provider im Rahmen einer Abonnementvereinbarung die Bereitstellung der Datenbank und der Hardwareinfrastruktur, je nach vereinbartem Service Level Agreement (SLA). Für den laufenden Betrieb der Datenbank dagegen bleibt der Nutzer zuständig. Wer auch darauf verzichten will oder mangels interner IT-Ressourcen muss, hat als dritte Option die Datenbanknutzung als Managed Service oder Managed Hosting zur Verfügung. Dabei kümmert sich der Provider um den kompletten Datenbankbetrieb und entlastet so die interne IT-Administration von diesen Aufgaben.

Der Typus der Datenbank bleibt davon unberührt. Sowohl relationale SQL- als auch dokumentenorientierte NoSQL-Datenbanken lassen sich als Cloud-Datenbank betreiben. Ein wichtiger Unterschied liegt jedoch in der unterschiedlichen Flexibilität. SQL-Datenbanken arbeiten mit festen Tabellenstrukturen. Änderungen an diesem Zeilen-Spalten-Schema verursachen, sofern überhaupt möglich, einen hohen Aufwand. Die jüngeren, Cloud-nativen NoSQL-Datenbanken dagegen arbeiten mit einem weitaus flexibleren Datenmodell. Es basiert auf JSON-Dokumenten statt auf Tabellen und lässt sich schneller und mit geringerem Aufwand ändern.

Wenn von Cloud-Datenbanken die Rede ist, wird häufig übersehen, dass ihr Einsatz nur dann wirklich Sinn ergibt, wenn neben den Daten auch die Applikationen in die Cloud wandern. Eine Cloud-Datenbank ist also nur dann sinnvoll, wenn auch Cloud-Applikationen die dort gespeicherten Daten nutzen. NoSQL-Datenbanken kommen mit der höheren Volatilität von Cloud-Apps besser zurecht als traditionelle SQL-Datenbanken: Deren Funktionsprinzip stammt aus einer Zeit, als Clouds noch das ausschließliche Fachgebiet von Meteorologen waren.

Vorteile

Für den Einsatz von Cloud-Datenbanken gibt es eine ganze Reihe guter Gründe. Häufig stehen dabei drei Argumente an vorderster Stelle: die bessere Skalierbarkeit (Abbildung 1), die schnelle und sichere Verfügbarkeit sowie die (vermeintlich) geringeren Kosten.

Für das Erweitern von Datenbanken, die man in der eigenen IT-Infrastruktur betreibt, muss man viel Geld in zusätzliche Hardware investieren und braucht mindestens ebenso viel Geduld, bis alles installiert ist. Cloud-Datenbanken dagegen skalieren quasi in Echtzeit, und das in beide Richtungen. Sie sind hochflexibel und lassen sich schnell an geänderte Anforderungen adaptieren. Damit kann man eine Umsatzflaute ebenso rasch abfedern wie einen plötzlichen Nachfrage-Boom, ohne dass dabei teure Hardware brachliegt oder hastig nachgeordert werden muss. Auch auf Kunstgriffe wie Thin Provisioning kann man verzichten. Das bedeutet eine rasche Verfügbarkeit von Datenbankressourcen abhängig vom aktuellen Bedarf. Langfristige Ressourcenplanung und vorauseilende kostenträchtige Hardware(über)dimensionierung fällt auf diese Weise flach.

Abbildung 1: Cloud-Datenbanken sind bei Skalierbarkeit und Verfügbarkeit (fast) nicht zu schlagen. Quelle: Couchbase

Gleichzeitig sinken die Anforderungen an die IT-Infrastruktur und die Administration. Teure Hardwareinstallationen können je nach Auslegung fast vollständig entfallen, entsprechend verringert sich auch der Platzbedarf dafür. Zudem ist beim Managed Hosting von Cloud-Datenbanken kein dezidierter Administrator für den Betrieb, den Support und die Wartung der Datenbank mehr nötig, da dies der Datenbankbetreiber übernimmt. Angesichts der angespannten Personallage in diesem Bereich ist das ein nicht unerheblicher Gesichtspunkt. Einen wichtigen Vorteil stellt dabei der einfache Umgang mit Cloud-Datenbanken dar, die sich per Web-Interface steuern und nutzen lassen.

Dafür muss der Anwender auf der anderen Seite beim Betrieb von Cloud-Datenbanken in schnelle und stabile Breitbandverbindungen investieren. Die Kosten dafür rechnen sich aber in der Regel gegenüber den gerade beschriebenen Einsparpotenzialen. Bei den Kosten für die Datenbanknutzung selbst gilt es jedoch eine gewisse Vorsicht walten zu lassen. Wirklich günstig sind bei den Hyperscalern häufig nur die Standardfunktionen. Für Sonderfälle oder individuelle Anforderungen werden oft hohe Zuschläge fällig.

Attraktiv dagegen ist die Zahlungsoption des Pay-per-use oder Pay-as-you-go, bei der lediglich die tatsächlich genutzten und verbrauchten Datenbankressourcen berechnet werden. Zu beachten gilt es dabei auch, dass man Investitionen in Hard- und Software steuerlich nur über mehrere Jahre hinweg abschreiben kann (Capex), während sich die Abokosten für Cloud-Datenbanken direkt als steuermindernde Betriebskosten (Opex) geltend machen lassen.

Migration und Sicherheit

Wer seine Daten – oder auch nur einen Teil davon – in die Cloud transferieren möchte, steht vor dem häufig unterschätzten Problem der Cloud-Migration. Je größer die Datenmenge, die es in die Cloud zu migrieren gilt, desto höher fallen die Kosten aus. Daher ist es sinnvoll, vorab zu klären, welche Daten man weiterhin benötigt und welche verzichtbar oder gar überflüssig sind und damit ein potenzielles Sicherheitsrisiko darstellen. Dazu kommt die Security- und Compliance-Frage nach sicherheitsrelevanten Informationen, etwa personenbezogenen Daten von Kunden, Partnern und Mitarbeitern.

Vor der Cloud-Migration sollte daher eine Bereinigung und Analyse der Daten erfolgen. Bei der Datenbereinigung geht es vorrangig um das Entfernen sogenannter ROT-Daten. Das sind redundante, obsolete und triviale Informationen. Die Datenanalyse soll klären, welche der verbleibenden Daten in die Cloud wandern dürfen und welche aus Sicherheitsgründen oder Fragen des besonders sensiblen geistigen Eigentums inhouse verbleiben sollen. Im Zuge dieser Cloud-Vorbereitung kann es zudem sinnvoll sein, einen eventuell vorhandenen Wildwuchs an Datenbanken im Unternehmen zu beenden. Vor dem Umzug in die Cloud gilt es daher abzuwägen, inwiefern es Sinn ergibt, sie in einem einheitlichen Datenbankmanagementsystem (DBMS) zu konsolidieren.

Beim Thema Security gehen die Cloud-Provider in Vorleistung und sorgen schon im eigenen Interesse für ein allgemeines Sicherheitsniveau, das oft höher liegt als die individuell installierten Schutzmechanismen von Private Clouds oder eigenen Rechenzentren. Auch datenbankkritische Themen wie Ausfallsicherheit, Failover und Backup regelt bei DBaaS und Managed Services der Provider. Ausfallsicherheit und Hochverfügbarkeit der Cloud-Datenbanken setzt er über sogenannte Verfügbarkeitszonen (Availability Zones) um, in denen Datenbank-Cluster gebildet werden. Dafür benötigt die Cloud-Datenbank entsprechende Replikationsmechanismen, beispielsweise die Cross Datacenter Replication (XDCR), die ständig zwischen diesen Clustern replizieren. Alternativ kann man auf Cloud-Ressourcen zurückgreifen, die im Hintergrund bereits redundant ausgelegt sind.

Ein häufig kolportiertes Problem von Cloud-Datenbanken ist die Geschwindigkeit. Die hängt aber in erster Linie nicht von der Datenbank selbst ab, sondern von der generellen Performance der virtualisierten Umgebung. Die Bandbreite ist hier groß, erreicht aber in der Regel auch bei den besten Clouds nicht die Performance von Bare-Metal-Installationen. Kritisch können dagegen die Latenzzeiten von Cloud-Datenbanken werden, die durch die prinzipiell zentralistisch angelegte Cloud-Architektur entstehen. Alle Daten müssen zuerst in ein oder mehrere, meist weit entfernte Rechenzentren transferiert und von dort wieder zurückgespielt werden. Das kostet mehr Zeit als der Zugriff auf interne Datenbankserver oder Datentransfers dorthin. Diese Einschränkung gilt vor allem für Echtzeitanwendungen, wie sie beispielsweise für Szenarien im Umfeld des Internet of Things (IoT) oder im Industrial Internet of Things (IIoT) typisch sind.

Edge Computing

Für Edge Computing spielen Cloud-Datenbanken daher nur eine untergeordnete Rolle. Dazu kommt die limitierende Abhängigkeit von ständig verfügbaren Online-Verbindungen. Schon ein kurzer Verbindungsausfall könnte ganze Produktionsstraßen zum Stillstand bringen. Ausfallsicherheit sieht anders aus. Deshalb erfolgt die Verarbeitung von Sensordaten in Echtzeit direkt vor Ort mithilfe von Edge-Datenbanken. Sie besitzen eine reduzierte, auf die Edge-Bedürfnisse zugeschnittene Funktionalität, haben etwa analytische Fähigkeiten zur Auswertung der peripheren Daten. Andererseits müssen sie weder besonders leistungsfähig noch hochskalierbar sein und brauchen auch keine Volltextsuche.

Für das anschließende Konsolidieren und Speichern der nicht mehr am Edge benötigten Daten kommen die Cloud-Datenbanken dann allerdings wieder ins Spiel. Dafür wird eine Datenbank gebraucht, die die dezentrale Architektur von Edge Computing abbildet und dessen Besonderheiten unterstützt. Die abgespeckte Edge-Datenbank und die Vollformatdatenbank in der Cloud müssen sich also verstehen und funktional ergänzen.

Die Cloud ist überall

Abgesehen davon sind Cloud-Datenbanken für praktisch alle denkbaren Einsatzszenarien geeignet. Funktional stehen sie intern installierten Datenbanken in nichts nach. Es gibt sie als SQL- und NoSQL-Datenbanktypen, die mit virtualisierten und containerisierten Umgebungen harmonisieren (Stichwort: Cloud Native). Sie binden in der Regel weniger Ressourcen, sind leicht verfügbar, hochskalierbar und meist kostengünstiger zu betreiben. (jcb)