Von Data Mesh zu Data-as-a-Service
Verteilte Anwendungen benötigen dezentrale Datenstrukturen. Auf diesen einfachen Nenner können die Diskussionen um neue Speichermodelle wie Data Mesh oder Multi Tenancy gebracht werden. Dahinter steckt ein ganz einfaches Prinzip, doch die Tücken liegen in der Umsetzung.
Die modernen Speichermodelle basieren auf dem Ansatz, Daten nicht mehr in zentralen Storage-Systemen und Datenbanken bereitzuhalten und bereitzustellen, sondern in dezentralen Daten- und Datenbank-Architekturen. Es ist müßig, sich darüber Gedanken zu machen, ob dies die Einführung nativer Cloud- und Cloud-Plattform-Technologien fördert oder nicht vielmehr eine logische Konsequenz aus der Struktur dieser immer beliebteren IT-Bereitstellungsmodelle ist. Fakt ist, dass insbesondere Hybrid- und Multi-Cloud-Umgebungen auf flexible, verteilte Speicherstrukturen angewiesen sind. Und dabei ist das Thema Edge Computing mit seinen peripheren Datenquellen und Speichersystemen noch gar nicht eingerechnet.
Jenseits der Hype-Begriffe steckt hinter diesen Datenmodellen ein Prinzip, das sich bereits auf allen Ebenen des Cloud-Schichtenmodells durchgesetzt hat. Cloud-Infrastrukturen werden in der Regel als Infrastructure-as-a-Service (IaaS), Plattformen als Platform-as-a-Service (PaaS) und Applikationen als Software-as-a-Service (SaaS) bereitgestellt. Was liegt also näher als der Gedanke, dass in diesem Kontext auch die Daten als Service (DaaS) zur Verfügung gestellt werden?
Dezentrale Speicher-Architekturen
Data Mesh wird häufig in erster Linie als ein Organisationsmodell definiert und verstanden. Die Zuordnung der Daten erfolgt dabei anhand der Unternehmensstruktur, also nach vertikalen (Entwicklung, Produktion, Vertrieb, Marketing etc.) und horizontalen (Personalwesen, Buchhaltung etc.) Segmenten oder Domänen. Jede Domäne bekommt dadurch mehr Eigenverantwortung für ihre eigenen Daten. Das soll die zentrale IT-Verwaltung entlasten und durch die größere Praxisnähe die Datenqualität und deren Verfügbarkeit sowie in der Konsequenz die Reaktions- und Aktionsgeschwindigkeit in den Abteilungen erhöhen. Dementsprechend verlagert sich die Datenspeicherung zwangsläufig von einer einzigen, zentralisierten Datenplattform zu mehreren dezentralen Datenspeichern. Denn mit monolithischen Speicherstrukturen ist dieses Organisations- und Zuständigkeitsmodell nicht umsetzbar. Das entbindet natürlich nicht von der Notwendigkeit, konsistente Datenbestände im Unternehmen zu haben. Die zentrale Konsolidierung erfolgt daher im Hintergrund in Data Warehouses oder Data Lakes unter Obhut der IT-Abteilung. Schon dieses Bild zeigt, dass sich die Komplexität des Daten-Managements tendenziell eher erhöht als verringert. Allerdings ändert sich die Balance der Arbeitsteilung zwischen der IT und den Domänen. Aus dem "Kunden" Fachabteilungen und dem "Dienstleister" IT-Abteilung werden – im Idealfall – Partner auf Augenhöhe mit definierten Zuständigkeiten. Das gängige Operationsmodell dafür sind DevOps oder SecOps, bei denen die Fachabteilungen und IT-Spezialisten zusammen an Projekten arbeiten.
Cloud-native Datenstrukturen
Auf der technischen Ebene geht es um die IT-Unterstützung für diese Organisationsstrukturen. Was bedeutet das für die Datenbank? Kurz zusammengefasst: Sie muss flexible Datenmodelle beherrschen, cloud-native und plattform-agnostisch sein, mit verteilten Umgebungen umgehen können, hochverfügbar und hochskalierbar (auch in Clustern) sein, die uni- und bidirektionale Cross-Datacenter-Replikation über mehrere Rechenzentren beziehungsweise Regionen hinweg beherrschen und fully managed verfügbar sein. Für viele Unternehmen ist auch die Unterstützung mobiler, dislozierter Arbeit ein wichtiger Punkt. Ein gerne goutiertes Extra ist zudem die Option zur Fast-Data-Migration ohne komplizierte ETL-Prozesse (Extract-Transform-Load). Und, häufig vergessen, aber alles andere als selbstverständlich: Sie muss ultraschnell sein, mit Latenzen im Sub-Millisekunden-Bereich.
Relationale Datenbank-Management-Systeme (RDBMS) tun sich mit diesem Anforderungsprofil schwer. Ihr Datenmodell mit fixer Spalten-Zeilen-Matrix ist zu unflexibel und veränderungsresistent. Als größter Vorteil gegenüber JSON-basierten Multi-Modell-Datenbanken (NoSQL) bleibt, wie die Abkürzung andeutet, eigentlich nur ihre weltweit verbreitete standardisierte Abfragesprache SQL. Doch auch die ist nicht mehr RDBMS-exklusiv, da erste NoSQL-Datenbanken auch den Einsatz von SQL-Statements möglich machen. Die Cloud- und Plattform-Agnostik ergibt sich als Anforderung aus der wachsenden Verbreitung von Hybrid- und Multi-Clouds. Eine Datenbank, die nur in ganz bestimmten Private oder Public Clouds funktioniert, ist für diese Szenarien nicht oder nur eingeschränkt geeignet. Ganz nebenbei wird so auch das gefürchtete Vendor Lock-in, also die Abhängigkeit von einem einzigen Anbieter, von vornherein ausgeschaltet.
Höhere Automatisierung und Autonomous Databases
Aus Sicht der Anwender ist der schnellere, direkte Datenzugriff in Data-Mesh-Strukturen Fluch und Segen zugleich. Sie müssen sich nicht mehr nur mit ihrem Fachgebiet, sondern auch mit IT-Fragen auseinandersetzen. Für sie ist es wenig sinnvoll, sich angesichts der rapide wachsenden Aufgabenfülle und Komplexität immer wieder mit Datenbankprogrammierung, -anpassung und -pflege beschäftigen zu müssen. Die Antwort auf diese Anforderungen aus der betrieblichen Praxis ist ein höherer Automatisierungsgrad durch autonome Datenbanken (Autonomous Databases). Die Automatisierung erfolgt dabei auf drei Ebenen:
- Monitoring der laufenden Datenbank-Prozesse und die Registrierung von Anomalien
- Entscheidung über eventuell zu treffende Aktionen bei Abweichungen
- Automatische Ausführung dieser Aktionen zur Behebung der Funktionsstörung
Damit wird eine durchgängige Performance, ein geringerer Administrationsaufwand, eine sinnvolle Auslastung der IT-Ressourcen sowie eine höhere Stabilität, Verfügbarkeit und Ausfallsicherheit erreicht. Dabei darf nicht vergessen werden, dass es enorme Unterschiede bei Art und Umfang der Automatisierungsfunktionen gibt. Als technischer Standard und Orientierung für Nutzer sind die Maturity-Levels der Cloud Native Computing Foundation (CNCF) hilfreich. Sie reichen von Stufe 1 (automatisiertes Konfigurationsmanagement oder App-Provisioning) bis zur höchsten Stufe 5. Dort werden unter anderem Funktionen wie Automated Availability, Automated Provisioning, Automated Update, Auto Failover, Auto Scheduling, Centralized Management, On-demand Dynamic Scaling, Failure Recovery, Cross Datacenter Replication (XDCR) und automatisches Vertikal- und Horizontal-Scaling gefordert.
Database-as-a-Service
Verteilte Umgebungen erhöhen die Anforderungen an die Datenbank – und damit auch an die Datenbank-Administration. Angesichts steigender Kosten und wachsenden Fachkräftemangels stieße das Prinzip Data Mesh damit an seine Grenzen – gäbe es nicht Database-as-a-Service (DBaaS). Die Nutzung einer Datenbank als Cloud-Service wird aus guten Gründen immer beliebter. DBaaS ist für eine Datenbank das, was ein Streaming-Dienst für Musik oder Videos ist. Verfügbarkeit, Ressourcen-Skalierung, aber auch Sicherheitsfunktionen wie Data Backup oder Data Recovery werden dabei vom Datenbank-Anbieter direkt oder von entsprechenden Providern übernommen. Unternehmen können die dafür anfallende "Flatrate" als operative Kosten (OpEx) abrechnen. Für die Datenbanknutzer vor Ort ist damit der Zugriff auf die gerade benötigten Daten jederzeit und überall möglich.
Das Servicemodell für Daten und Datenbanken erleichtert so die Umsetzung von Data-Mesh-Szenarien enorm. In Verbindung mit den hohen Automatisierungsleveln von NoSQL-Datenbanken machen sie Data Mesh erst praktikabel nutz- und umsetzbar.
