Streaming und Mainframe: alte Hardware-Architektur trifft moderne Software
Data Streaming mit Mainframes ist möglich, obwohl beide Techniken unabhängig entwickelt wurden. Der Prozess nicht trivial, aber sinnvoll, zeigt unser Interview.
Wollen Unternehmen auf digitale Geschäftsmodelle setzen, entpuppen sich ihre in die Jahre gekommenen Data-Warehouse- und Messaging-Architekturen oft als hinderlich. Ein neuer, Streaming-getriebener Ansatz hilft, die Flexibilität, Agilität und Skalierbarkeit der Infrastruktur zu erhöhen – insbesondere, wenn auch Daten vom Mainframe einbezogen werden müssen.
Denn mit Echtzeit-Datenanalyse-Technologien ist es inzwischen möglich, die als abgeschottete Silos verrufenen Mainframes in moderne Streaming-Plattformen einzubinden. Dazu gehören neben der freien Software Apache Kafka, die insbesondere zur Verarbeitung von Datenströmen dient, zum Beispiel auch Apache Kudu (als schnelle Analyse-Engine für Hadoop) oder Spark Streaming, ein Framework zum Schreiben von Anwendungen mit Streaming-Daten.
Da die Streaming-Plattformen ohne die Mainframes im Sinn entwickelt wurden, ist ein gangbarer Weg gefragt, Mainframe-Daten in einem Format einzuspeisen, das die Streaming-Plattformen unterstützen. Es gibt verschiedene Optionen, die das theoretisch ermöglichen. Wir haben Kai Wähner gefragt, welche es gibt und worauf es dabei ankommt.
Herr Wähner, worum handelt es sich bei dem Streaming überhaupt, das Confluent auf Basis von Kafka implementiert? Dieser Begriff ist durch seine Verwendung bei Endanwendern ziemlich schwammig im Sprachgebrauch.
In traditionellen Umgebungen liegen Daten an ihre Applikationen gekettet in Datensilos. Die Applikationen sind wiederum über maßgeschneiderte Konnektoren mit anderen Applikationen fest integriert, sodass jede flexible übergreifende Datennutzung sehr aufwändig und umständlich ist.
Daten-Streaming entkoppelt Anwendungen voneinander und bringt die Daten in Fluss, was gerade in weit verteilten Umgebungen, beispielsweise bei Filialbanken oder Einzelhandelsketten, wichtig ist. Ereignisse – das kann alles sein, von einem Online-Kauf bis zu einer Systemstörung – generieren in Echtzeit Daten, die dann an die Streaming-Plattform übermittelt werden. Diese speichert sie unverändert in der Reihenfolge ihres Eingangs, damit wird sie zur zentralen Informationsquelle.
Zudem werden die Daten inhaltlich sogenannten Topics zugeordnet, die sich je nach Bedarf der Anwendungen maßschneidern lassen. Eine moderne Streaming-Plattform kann auch einfach an traditionelle Datenquellen, etwa Datenbanken, angebunden werden und die Ereignisdaten so mit Bestandsdaten verbinden. Greifen Applikationen auf Streaming-Plattformen zu, abonnieren sie die von ihnen benötigten Topics und bekommen so automatisch die für sie wichtigen, jeweils aktuellsten Daten in Echtzeit. Diese bringen die Apps selbst in das für sie passende Format, der komplexe ETL-Vorgang entfällt also.
Anbinden lässt sich praktisch jede Applikation über geeignete Konnektoren. Diese Legacy oder auch Cloud-nativen Konnektoren werden in einer modernen Streaming-Plattform oft schon bereitgestellt.
Es geht also um eine Dateninfrastruktur, die sich auf Daten in Bewegung konzentriert: Warum gehören Mainframe-Daten dann überhaupt in eine solche Streaming-Plattform? Schließlich implementieren Mainframes doch eigentlich das Konzept einer zentralen Datenhaltung.
Dass sich Mainframes oder andere überkommene Plattformen in Streaming-Umgebungen wie das auf Apache Kafka basierende Confluent integrieren lassen, ist einer ihrer wesentlichen Vorteile: Denn Banken, Versicherungen, Einzelhändler oder große Industrieunternehmen halten in ihren Mainframe-Applikationen unermesslich große und wertvolle Datenbestände. Zudem sind die Mainframe-Applikationen meist sehr funktional und leistungsfähig, dazu langjährig bewährt. Auf sie zu verzichten, ist weder nötig noch sind sie einfach abzulösen.
Einerseits sollen die ständig neu entstehenden Echtzeit-Events etwa aus Handel oder IoT-Umgebungen dokumentarisch genau gespeichert und bereitgestellt werden, andererseits auch die Bestandsdaten als Erkenntnisquelle dienen. Erst die gemeinsame Nutzung beider erzeugt oft neue Einsichten und ermöglicht neue Geschäftsmodelle.
[1]Streaming Erfolgsgeschichten
Können Sie uns einige typische Beispiele für Streaming mit dem Mainframe nennen, die Ihre Kunden schon erfolgreich realisiert haben?
Die Liste möglicher Anwendungen ist lang. Dazu gehören eine Rundumsicht auf Kunden und ihr Verhalten (360-Grad-Kundensicht), Betrugsvorbeugung und -erkennung, im Retail das Onboarding von Verkäufern, die Abstimmung von Kundendaten, die Echtzeit-Nutzung von Verkaufsdaten einzelner Standorte oder die Rationalisierung der Lieferkette.
Neben vielen fachlichen Use Cases gibt es auch technische Gründe, darunter die IT-Modernisierung durch die Entlastung des Mainframes – das sogenannte Mainframe-Offloading. Die Streaming-Plattform ermöglicht hierbei die Korrelation von Mainframe-Daten mit ERP-Daten und neuen (non-Mainframe) Daten wie IoT-Sensor-Daten. So lassen sich mit dem Mainframe ganz neue Use Cases in cloud-nativen Umgebungen aufbauen.
Ganz aktuell durchläuft die Nord/LB eine IT-Transformation, in deren Verlauf sie mit Hilfe zunächst von On-Premises-Confluent und nun auch der Confluent-Cloud-Plattform die Daten einer neuen SAP-basierten Kernbankanwendung in das vorhandene Big-Data-System einbringt. Da das Big-Data-System schnell und unkompliziert Zugang zu den Confluent-Daten hat, können sich die Data Scientists auf die Erstellung ihrer Modelle konzentrieren.
Wie einfach oder wie kompliziert ist es im Vergleich zu anderen Plattformen, den Mainframe als Datenquelle für das Streaming zu nutzen?
Das kommt natürlich auf die Plattform an. Bei Confluent ist es auf vielfältige Weise möglich. So gibt es Konnektoren zu Db2 und IBM MQ. Wir können über Kafka Connect und MQ Source- und Sink-Connector Teile der Infrastruktur auf z/OS statt auf klassischem Linux laufen lassen. Das kann Leistung und Kosten optimieren. Dadurch lassen sich ganze Prozessketten von Ende zu Ende orchestrieren, zu denen auch Mainframes gehören.
Allerdings wird in vielen unserer Projekte auch Third-Party-Middleware, etwa IBM IIDR, eingesetzt, um den Mainframe anzubinden. Das gilt besonders, wenn Kunden kein MQ einsetzen, für das wir ja selbst eine Anbindung haben. Für Anbindungen an Nicht-Mainframe-Anwendungen wie Snowflake oder SAP liefern wir ebenfalls Konnektoren. Außerdem gibt es Toolkits, mit denen sich sogar Individualsoftware oder stark angepasste Standardsoftware einbinden lassen.
Oft sind die reinen Daten ja besser über die zugehörigen COBOL-, Assembler- oder PL/1-Programme nutzbar: Sind mit Confluent auch Mainframe-Programme als Datenquelle nutzbar? Falls ja: Worauf ist dabei zu achten? Falls nein: Warum (noch) nicht – oder ist das gar nicht sinnvoll?
Natürlich können wir nicht alles. Grundsätzlich lassen sich Anwendungen über Programmiersprachen wie Java oder C++ oder auch über Web-Service-Schnittstellen wie HTTP/REST anbinden. Wo möglich, werden existierende COBOL-, Assembler- oder PL/1-Anwendungen nicht mehr angefasst, weil Entwickler-Knowledge fehlt und solche Prozesse mit hohem Risiko behaftet sind.
Falls für den individuellen Fall vorhanden, benutzen wir Confluent-Konnektoren oder aber Mainframe-spezifische Third-Party-Middleware. Letztere ist in der Regel nötig, sobald Anwender kein MQ als Integrationsschnittstelle benutzen.
Integrations- und Migrationsprojekte auf dem Mainframe sind selten einfach. Dabei sollte man mit viel Fingerspitzengefühl vorgehen. Der Prozess ist bei aller technischen Hilfestellung auch organisatorisch anspruchsvoll. Es gibt unterschiedliche Methoden, je nachdem, wie diese Applikation aussieht. Beim reinen Lift-and-Shift oder Rehosting lässt sich die App einfach in einen Container packen und auf die neue Plattform, etwa die Cloud, verschieben. Das ist aber bei klassischen Mainframe-Apps, die über Jahrzehnte gewachsen sind, eher selten.
Beim Re-Enginieering werden manche Teile der Apps containerisiert und mit einer API-Schicht zur Kommunikation versehen, hier spricht man auch vom Wrapping. Das ist deutlich aufwändiger. Und schließlich kann man Applikationen komplett neu in einer modernen Architektur schreiben, das sogenannte Refactoring. Das ist in der Regel der aufwändigste Weg.
Unterschiede zwischen Kafka und anderen Integrationstechniken
Und was unterscheidet Streaming-Systeme wie Kafka / Confluent von anderer Middleware, die über Techniken wie SOA, EAI, REST oder API für Integration sorgen soll?
Gegenüber klassischen Middleware-Ansätzen hat Daten-Streaming mit der Confluent-Plattform eine Reihe großer Vorteile: Sie wird auch mit asynchronen Vorgängen fertig, kann heterogene Datensätze genau wie ein ETL-Tool oder ein ESB integrieren und schafft gleichzeitig einen hohen Durchsatz bis hin zu Gigabytes pro Sekunde.
Die klassischen Message-Broker stoßen bei Echtzeit und hoher Skalierbarkeit an ihre Grenzen und müssen außerdem mit anderen Integration- und Streaming-Plattformen kombiniert werden, um verschiedene Systeme zu integrieren und Daten zu korrelieren. APIs und REST kommen auch in Confluent-Infrastrukturen vor. Das sind modernere, mit Clouds und mit Microservices kompatible Methoden, Applikationen zur Kommunikation mit ihrer Umgebung zu befähigen.
Wie sorgt Confluent dafür, dass beim Streaming nicht die Sicherheit und Vertraulichkeit kritischer Mainframe-Daten gefährdet wird?
Confluent ist ganz klar auf Sicherheit ausgelegt. Die Ereignisdaten in der Plattform dienen als „Single Source of Truth“, weil sie im Originalformat und unveränderlich in Confluent gespeichert bleiben, statt wie sonst üblich allerlei Transformationen unterzogen zu werden. Anwender haben ja keinen direkten Zugriff beispielsweise auf den Mainframe, wenn sie Daten über Confluent abfragen. Wer Daten aus Confluent abruft, bekommt sie, egal woher sie stammen, sicher, schnell, garantiert und zuverlässig. Mechanismen wie Authentisierung, Autorisierung und Verschlüsselung stehen bereit, um die Daten in der Plattform zu sichern, und unsere Kunden können sie je nach ihrem Bedarf einsetzen.
Zudem liegt unser Fokus auf „Data Governance“, also Themen wie Datenqualität, wer ist berechtigt, auf Daten zuzugreifen et cetera. Wir wollen Sichtbarkeit und Transparenz über die gesamte Streaming-Pipeline herstellen – vom Mainframe bis beispielsweise zu Snowflake. Da Confluent eine skalierbare Echtzeit-Verwaltung bietet, lassen sich damit auch regulatorische Anforderungen wie BAIT (Bankaufsichtliche Anforderungen an die IT) oder die DSGVO (Datenschutz-Grundverordnung) umsetzen.
Struktur für Machine Learning
Wie sorgt Confluent nach der Extraktion der benötigten strukturierten und unstrukturierten Rohdaten dafür, dass die Mainframe-Daten sinnvoll in Analytics- und KI-/ML-Modellen nutzbar sind?
Genau hier zeigt sich der Vorteil des Pull-Mechanismus unserer Streaming-Plattform. Denn die jeweiligen KI-Applikationen ziehen, mit entsprechenden Konnektoren ausgerüstet, über die zuvor definierten Topics, die die Plattform speist, nur solche Daten, die auch wirklich benötigt werden. Die Umsetzung in das benötigte Format der jeweiligen analytischen Anwendungen erfolgt automatisiert außerhalb der Plattform an der Schnittstelle.
Das heißt, die Data Scientists können sich auf die Generierung optimaler Modelle konzentrieren statt auf Datentransformationen. Parallel nutzen immer mehr Kunden die Streaming-Plattform für das Deployment der Modelle. Im Gegensatz zum Modell-Training im Batchprozess des Data Lake ist beim „Model Scoring“, zum Beispiel für Betrugserkennung oder Predictive Maintenance, hochskalierbare und zuverlässige Echtzeitdatenverarbeitung gefragt.
Verstehe ich das richtig: Es geht beim Streaming generell um Modernisierung der Datenarchitektur des Unternehmens – und damit auch um den Abschied vom Silo-Denken, das so gerne mit dem Mainframe assoziiert wird?
So ist es. Denn Silos stehen der Etablierung durchgängiger Prozesse, die von vorn bis hinten orchestriert sind, im Weg. Dennoch sind sie die Basis digitaler Wertschöpfungsketten und Geschäftsmodelle. Bekommt man beispielsweise Verkauf, Beschaffung und Kundendienst unter ein Prozess-Dach, steigert dies das Kundenerlebnis meist beträchtlich.
Herr Wähner, vielen Dank für das Interview! Die vorherige Ausgabe unserer Mainframe-Interviews hat beleuchtet, warum die DATEV weiterhin auf ihre etablierten Mainframes [2] setzt – und das, obwohl sie gar nicht mehr müsste. In Folge 9 ging es außerdem schon einmal um Mainframes und moderne Projekte: Wie öffnet man die vermeintlichen Silos mit Open-Source-Software [3]? (jvo [4])
URL dieses Artikels:
https://www.heise.de/-7483239
Links in diesem Artikel:
[1] https://www.heise.de/ix/
[2] https://www.heise.de/news/Mainframe-wir-muessen-ihn-nicht-mehr-betreiben-aber-wir-wollen-7316379.html
[3] https://www.heise.de/news/Mainframes-in-der-modernen-IT-Mit-Open-Source-die-alten-Silos-oeffnen-7218385.html
[4] mailto:jvo@ix.de
Copyright © 2023 Heise Medien