Wie in jedem anderen Unternehmen ab einer gewissen Größe, gibt es auch in der DKB umfangreiche Anforderungen an die Datenintegration. Daten aus verschiedensten Quellen müssen zusammengeführt, transformiert, überwacht und qualitätsgesichert werden. Eine Vielzahl von Datenhaushalten ist in einer heterogenen Landschaft daran beteiligt, sowohl den Kund*innen, als auch den Mitarbeitenden zu jedem Zeitpunkt die gewünschte Information zur Verfügung zu stellen und ihre jeweiligen Arbeitsprozesse zu unterstützen. Zudem gilt es nicht nur im regulierten Umfeld, den Überblick zu wahren, welche Daten wie durch unsere Systeme fließen, woher sie kommen, wie sie transformiert und welchen Systemen sie dann zugeführt werden.
Diese Anforderungen gelten nicht erst seit dem Cloud-Zeitalter und sind auch schon auf unseren bestehenden On-Premise-Systemen erfüllt. Unsere Datenintegrationsplattform erweist uns dabei bereits seit langer Zeit gute Dienste. Allerdings ergeben sich durch den Weg in die Cloud neue Herausforderungen, denn wir arbeiten nicht mehr mit einmal installierten Server-Systemen mit unveränderlichen Adressen. Die Elastizität der Cloud führt dazu, dass hier neue Wege beschritten werden müssen. Die Heterogenität nimmt zu, die Anzahl der beteiligten Systeme ändert sich laufend und auch datenführende Systeme können automatisch erzeugt und wieder zerstört werden.
Zudem existiert in der DKB mittlerweile eine Vielzahl an IT-Projekten, die zumindest teilweise cloud-basierte Systeme beinhalten, und viele dieser Systeme wollen in der einen oder anderen Form Daten verarbeiten.
Damit nicht jedes Projekt bzw. Team eigene datenverarbeitende Systeme, Infrastrukturen und Prozesse aufbauen und dabei eigene qualitätssichernde Maßnahmen anhand der zu verarbeitenden Daten ableiten muss, und um eine zentrale Data Lineage sicher zu stellen, bauen wir in der Cloud eine zentrale Datenverwaltung und Datenintegration auf, die bei uns unter dem Namen „Cloud Data Platform“ firmiert.
Diese Lösung ähnelt in vielen Punkten einem Data Lake, wie er bei vielen anderen Unternehmen im Einsatz ist – allerdings mit einem etwas anderen Fokus: In der Regel werden Data Lakes mit dem Ziel aufgebaut, eine Analytics-Plattform zu schaffen und Mehrwert für das Unternehmen durch Business Intelligence zu schaffen. In unserem Fall ist der Haupteinsatzzweck aber, eine zentrale Datenversorgung für verschiedenste abnehmende Systeme zu schaffen, die den modernen Ansprüchen an Regulatorik, Datenschutz, Dynamik und Skalierbarkeit genügt, dabei aber auch moderne agile Arbeitsprozesse unterstützt. Daher bezeichnen wir unser Projekt auch gerne als zentrale Datendrehscheibe in der Cloud.
Das Herzstück unserer Cloud Data Platform ist ein Kubernetes-Cluster, der die ausführende Basis bietet, auf welcher die verschiedenen Datenintegrationswerkzeuge arbeiten. Sowohl die Datentransformationen selbst, als auch Scheduling, Steuerungs- und Monitoringprozesse, Metadatenmanagement und Datenqualitätssicherung, werden sämtlich in Kubernetes ausgeführt, orchestriert und überwacht, deklarativ durch Helm-Releases beschrieben.
Kubernetes bietet uns die Möglichkeit, unsere Anwendungen auf einfache Weise hochverfügbar zu betreiben und auf spezielle Ressourcenanforderungen dynamisch zu reagieren. So können wir beispielsweise einfache Datenstrecken oder Transformationen kleinerer Datenmengen auf günstigen Instanz-Typen ausführen, während das Training von komplexen Data-Science-Modellen auf deutlich teureren, GPU-bestückten Instanzen ausgeführt wird. Zudem können kritische Dienste automatisch über mehrere Ausfallzonen verteilt werden, was es ermöglicht, dynamisch auf Lastspitzen zu reagieren.
Aufbau und Verwaltung dieser Cloud-Ressourcen bringen dabei eine eigene Komplexität mit. Das Schlüsselwort, um hier nicht den Überblick zu verlieren, lautet „Infrastructure-as-Code“: Die Infrastruktur wird als Software betrachtet und kann genauso entwickelt werden wie jede andere Software auch. Wir setzen hier verschiedene Werkzeuge ein, zum einen Terraform als Quasi-Standard für herstellerübergreifende Infrastrukturentwicklung, zum anderen Crossplane, das wegen der engen Verzahnung mit Kubernetes einen schnellen Einstieg für Entwickler*innen erlaubt und im Kubernetes-Workflow keinen Bruch erzeugt.
Als stark reguliertes Unternehmen müssen wir dabei besondere Sorgfalt walten lassen: Jeder Code muss vor dem Merge in den Main-Branch einem Review durch andere Entwickler*innen unterzogen werden, und die nachgelagerten Integrations- und Deployment-Prozesse müssen einen hohen Automatisierungsgrad aufweisen. Das erleichtert uns nicht nur die Arbeit und erlaubt hohe Entwicklungsgeschwindigkeiten, auch die regulatorischen Anforderungen werden durch automatisierte Lösungen reibungsfrei unterstützt. Konkret setzen wir bei der Automatisierung von Integration und Deployment auf GitOps: Container Images und Helm-Releases werden nach dem Merge automatisch erzeugt, versioniert und in ihren jeweiligen Repositories abgelegt sowie in Git referenziert. Von dort werden die Applikationen mittels eines Agenten auf den Clustern ausgerollt, als Agent kommt bei uns das Werkzeug Flux zum Einsatz.
Sowohl Infrastruktur als auch die Datenintegrationsstrecken selbst, notwendige unterstützende Applikationen und datenverarbeitende Microservices, sowie alle beteiligten Komponenten werden dabei grundsätzlich nach den gleichen Prinzipien entwickelt, getestet und ausgerollt.
In datengetriebenen Projekten wie unserem gibt es natürlich nicht nur Software und Systeme aufzubauen und zu verwalten, auch die Daten selbst bedürfen spezieller Aufmerksamkeit. Datenstrecken müssen überwacht, hohe Datenqualität muss langfristig sichergestellt, Metadaten müssen neben den eigentlichen Daten ebenso verwaltet und den Anwendern verfügbar gemacht werden; die Dokumentation der Data Lineage muss aktuell sein und dabei müssen Lösch- und Aufbewahrungspflichten sowie datenschutzrechtliche und sicherheitstechnische Erfordernisse gewahrt bleiben.
Um alle diese Aufgaben möglichst effektiv wahrnehmen zu können, wurde ein interdisziplinäres Team geschaffen, das den Aufbau und Betrieb der Cloud Data Platform bereichsübergreifend verantwortet. Hier arbeiten neben ETL- und Infrastruktur-Entwickler*innen auch Data-Governance-Expert*innen, Daten-Architekt*innen, Business Analysts und Product Owner zusammen, um in einem gemeinsamen agilen Prozess nach Scrum die Plattform weiterzuentwickeln und zu betreiben. „You build it – you run it“ lautet unser Motto.
Der strenge Fokus auf automatisierte Datenversorgung erlaubt uns, relativ einfach ein hohes Sicherheitsniveau zu erreichen, denn es gibt schlicht keinen Zugriff auf Daten in unserer Plattform außerhalb der gegengelesenen und getesteten ETL-Prozesse. Andere Use Cases wie zum Beispiel aus dem Analytics- und Reporting-Bereich werden daher zum jetzigen Zeitpunkt nicht unterstützt. Das wird sich natürlich noch ändern müssen, wenn wir das volle Potenzial einer solchen zentralen Datenplattform entfalten wollen. Daher arbeiten wir daran, ein eigenes Zugriffskontrollsystem zu schaffen, das mit unseren Analytics-, Data-Science- und Reporting-Werkzeugen zusammenarbeitet und deren Anwendungsfälle ermöglicht, dabei unerlaubten Datenzugriff verhindert und erlaubten Datenzugriff überwacht.
Das aus anderen Data Lakes bekannte Lambda-Architekturmuster beinhaltet auch einen sogenannten „Speed Layer“, also eine Schicht mit Werkzeugen zur Verarbeitung von Datenströmen. Auch das steht auf unserer Agenda, um Datenversorgung in near-real-time möglich zu machen und dadurch ganz neue technische Möglichkeiten bei den abnehmenden Systemen zu eröffnen.
Es stehen uns also noch einige spannende Aufgaben bevor – technologisch am Puls der Zeit, mit modernen Arbeitsmethoden und in einem Umfeld, wo der digitale Wandel ernst gemeint ist und Schlagworte wie #Nachhaltigkeit und #TechBank nicht einfach nur leere Slogans sind.