Mainframes in der modernen IT: Mit Open Source die alten Silos öffnen
Statt sie generell durch neue Architekturen zu ersetzen, sollte man etablierte Mainframes lieber in moderne Infrastrukturen einbinden, findet Martin Reusch.
- Berthold Wesseler
Modern und Mainframe – diese beiden Begriffe sind für Martin Reusch kein Widerspruch. Der Director Application Modernization & Connectivity DACH bei Micro Focus vertritt die These: Bevor man alte Kernsysteme in der IT einfach durch neue ersetzt, sollte man bedenken, dass „anders“ und „neu“ nicht unbedingt besser ist als „alt“ und „bewährt“. Letzteres gilt gerade für Legacy-Systeme auf dem Mainframe, die das Kerngeschäft unterstützen.
Denn einen „Königsweg“ hin zu einer zeitgemäßen und flexiblen IT-Infrastruktur gibt es nicht. Vielmehr geht jedes Unternehmen seinen eigenen Weg, auf dem sowohl die Cloud als auch der Mainframe eine wichtige Rolle spielen können. Worauf es dabei ankommt, erklärt er uns im Interview.
Herr Reusch, Sie sehen den Mainframe-Markt durch die COBOL-Brille. Wie groß ist dieser Markt, bei dem es ja nicht nur um IBM z geht, sondern auch um Hersteller wie Fujitsu (BS2000), Atos/NEC (GCOS) oder Unisys (Clearpath)? In Deutschland, aber auch weltweit?
Dass wir uns inzwischen so sehr auf IBM z fokussieren, hat einen guten Grund: Was den Business-Case angeht, sind die anderen Systeme inzwischen zu vernachlässigen. Sie werden nur noch in so geringer Zahl genutzt, dass sie wirtschaftlich schlicht nicht mehr relevant sind.
Bei IBM z sieht die Situation ganz anders aus – dieses System ist fest in der Geschäftswelt verankert. Im deutschsprachigen Raum sprechen wir hier von einer Nutzerzahl im höheren zweistelligen Bereich. Diese Zahl klingt auf den ersten Blick vielleicht klein, doch die Nutzer sind echte „Big Player“ der Wirtschaft: große etablierte Banken, Versicherungen, aber auch Autohersteller zählen dazu. Weltweit kann man in etwa von 3 000 IBM-z-Kunden ausgehen.
Wie stabil ist dieser Markt? Oder anders gefragt: Aus welchen Gründen wandern Mainframe-Anwender auf andere Plattformen ab?
Basierend auf den uns vorliegenden Informationen kann man sagen, dass der z/OS-Markt in Europa – was die Gesamtleistungskapazität angeht – wächst, allerdings die Zahl der Unternehmen eher sinkt. Auch bleibt die Mainframe-Welt beim Cloud-Boom nicht außen vor – wir selbst sind Teil dieses Trends, Mainframe-Anwendungen direkt in die Cloud zu migrieren, denn wir unterstützen unsere Kunden bei diesem Schritt.
So hat gerade AWS auf der Re:Invent „Mainframe Migration Services“ veröffentlicht, die unter anderem auf unserer Technologie basieren. Dort haben unsere beiden Unternehmen auch eine strategische Partnerschaft geschlossen.
Der Mainframe hat nach wie vor für viele Unternehmen seine Berechtigung. Aber es gibt natürlich einige legitime Gründe, die für ein Re-Platforming sprechen. Üblicherweise werden hier die Kosten der Mainframe-Umgebungen angeführt, ebenso wie die Bindung an einen Anbieter (Vendor Lock-in). Ein weiteres Problem, das unseren Kunden häufig begegnet ist, dass die etablierten Mainframe-Experten langsam in den Ruhestand gehen und es an Nachwuchs fehlt. Zudem benötigen Unternehmen heute mehr Flexibilität und Skalierbarkeit, was sich in Cloud-Umgebungen einfacher verwirklichen lässt.
Stichwort Anwendungsmodernisierung: Welche Gründe sprechen dafür, die COBOL-Programme nach einem Re-Factoring weiter auf dem Mainframe zu betreiben?
Was seinen Aufgabenbereich angeht ist der Mainframe absolut auf dem Stand der Technik. Wenn es zum Beispiel um repetitive Aufgaben mit hohem Datendurchsatz geht, gibt es gute Gründe, COBOL-Anwendungen auf dem Mainframe zu betreiben.
Einerseits gehören Mainframes zu den sichersten Systemen überhaupt, andererseits werden sie bei Durchsatz- und Transaktionsraten auch heute noch kaum übertroffen. Auch was die Datenhaltung betrifft leistet der Mainframe immer noch gute Dienste, schließlich wurden die Systeme genau dafür ausgelegt, große Datenvolumina schnell und sicher zu verwalten.
COBOL-Anwendungen: Genauso skalierbar wie andere Cloud-Applikationen
COBOL ist internationaler Standard. Daher sind COBOL-Programme grundsätzlich auch einfacher als andere Programme auf eine neue Plattform migrierbar. Wie hoch ist dieser Aufwand dennoch?
Da COBOL eine standardisierte Sprache ist und auf den meisten Plattformen (Linux, Windows) ebenso lauffähig ist, wie auf gängigen Managed-Systems wie JVM oder .NET, stellt die Migration des reinen COBOL-Teils keine große Hürde dar. Der Grund, warum Migrationsprojekte dennoch eher in Monaten bis Jahren zu sehen sind, ist, dass die gesamte genutzte Mainframe-Infrastruktur ersetzt werden muss – sprich Security, Transaktionssysteme, Datenhaltung, Sicherung, Monitoring, Printing etc.
Es geht also weniger um die Komplexität von COBOL, schließlich wurde die Sprache mit der Anforderung entwickelt, einfach zu sein. Die größere Herausforderung ist das Herauslösen der Programme aus der vorhandenen Infrastruktur des Mainframes.
Welche Voraussetzungen muss ein Scale-Out-Cluster beziehungsweise eine Cloud-Plattform mitbringen, damit die Portierung einer Mainframe-Anwendung überhaupt funktionieren kann?
Die technischen Voraussetzungen unterscheiden sich grundsätzlich nicht gegenüber denen üblicher Applikationsserver. Allerdings müssen die bestehenden Mainframe-Anwendungen skalierbar sein oder skalierbar gemacht werden. Dann sind COBOL-Anwendungen ebenso skalierbar wie andere Cloud-Applikationen. Wir haben zumindest mit unseren Lösungen und den gängigen Cloud-Providern noch keine Einschränkungen erlebt.
Mit Blick auf die Anwendung selbst geht es dann um Themen wie „stateful“ versus „stateless“ im Transaktionsbereich, wobei Mainframe-Applikationen häufig stateful sind. Auch die Aufteilung einer Nachtverarbeitung, sprich eines Batchbetriebs, auf parallele Maschinen erfordert häufig eine Änderung der Anwendungsarchitektur.
Wann ergibt eine Umstellung der bewährten COBOL-Programme in eine modernere Programmiersprache wie zum Beispiel Java Sinn? Welche Vorteile bringt das?
Meiner Meinung nach ist das in den seltensten Fällen wirklich sinnvoll. Die Umstellung einer Anwendung auf eine andere Sprache ist mit hohen Risiken behaftet. Dabei kann es sich beispielsweise um den Verlust undokumentierter Funktionen handeln. Hier muss man sich vor Augen führen, dass COBOL-Anwendungen nicht selten eine Lebensdauer von 20 bis 40 Jahren haben. Da kann einiges zusammenkommen.
Weiter bedeutet diese Umstellung meist eine Neuentwicklung, da normalerweise auch eine neue Architektur eingeführt wird. Man muss also auch diesen Aufwand einkalkulieren. Da stellt sich dann schnell die Frage nach dem Mehrwert: Was hat man davon, das Abbild derselben Logik in einer anderen Sprache vorliegen zu haben?
Zuletzt kann man sich auch noch fragen, wie modern Java überhaupt ist, die Sprache ist schließlich auch bereits über 25 Jahre alt. In den allermeisten Fällen würde ich davon abraten, eine gutlaufende COBOL-Anwendung ohne Notwendigkeit in eine andere Sprache zu überführen.
Open-Mainframe & Zowe: Open-Source-Projekte für den Mainframe
Welche typischen Stolpersteine sind bei solchen Migrationsprojekten aus dem Weg zu räumen?
Verantwortliche sollten immer das Gesamtbild im Auge behalten, insbesondere die Migration der Mainframe-Infrastruktur hin zu einer Open-World-Infrastruktur. Der Wechsel der Zeichenkodierung von EBDIC nach ASCII führt zum Beispiel zu Änderungen in der Sortierreihenfolge. Dies gilt es zu beachten und gegebenenfalls im Code anzupassen.
Datenhaltung ist ein weiterer kritischer Punkt, da auf dem Mainframe häufig die Daten noch in sequenziellen Dateien (VSAM etc.) vorliegen, aber in der „Open World“ meist mindestens in relationalen Datenbanken abgelegt werden. Eine weitere Herausforderung kann der Wechsel der Datenbank von DB2 z auf z/OS zu den verbreiteten Datenbanken MS SQL, DB2 UDB, Oracle etc. darstellen. Und die Wahl der neuen Infrastruktur in der „Open World“ kann sich auf die Performance der Anwendungen auswirken.
Welche Rolle kann Open Source bei der Modernisierung von Mainframe-Programmen spielen? Auch auf dem Mainframe selbst?
Dank Open Source können in der Community verbreitete und beliebte Tools wie beispielsweise Jenkins, Jira und GIT zum Einsatz kommen, aber auch Open-Source-basierte Entwicklungsumgebungen wie Eclipse. Dies kann einerseits bei der Migration in die „Open World“ helfen, andererseits aber auch bei der Integration von DevOps-Ansätzen auf dem Mainframe selbst unterstützen.
Welche Hilfestellung können dabei das Open-Mainframe- und speziell das Zowe-Projekt liefern?
Ich halte diese Projekte für sehr sinnvoll, da sie zunächst einmal dafür sorgen, dass grundlegende Mainframe-Skills nicht verloren gehen, beziehungsweise neu erlernt werden können. Außerdem wird hier wichtige Arbeit geleistet, damit Mainframe-Technologien mit Standard-Schnittstellen (zum Beispiel REST) genutzt werden können.
Im größeren Rahmen betrachtet sorgen solche Projekte auch dafür, das Silo des Mainframes aufzubrechen, sodass sich die dortigen Ressourcen besser in das Gesamtökosystem (on Premises wie Cloud) einfügen lassen.
Anders gefragt: Wie lassen sich die bewährten und mit innovativen Anwendungsprogrammen unter einen Hut bringen, sodass sie integriert zusammenarbeiten und sich im Sinne von DevOps gemeinsam weiterentwickeln und betreiben lassen?
Wie gesagt kann der Mainframe auch für DevOps befähigt werden. Anwendungen lassen sich von dort aber auch auf Windows oder Linux migrieren, um dann entweder on Premises oder in der Cloud zu laufen, eingebettet in eine moderne DevOps-Landschaft.
Unterstützend können COBOL-Anwendungen modernisiert werden und zum Beispiel bequem – natürlich Tool-gestützt – in Webservices oder Micro-Services umgebaut werden, um die Anforderungen an innovative Anwendungsprogramme mit der bewährten Businesslogik zu verbinden. Gegenseitige Aufrufe, also von Java nach COBOL oder zurück, sind heute kein Problem mehr. Außerdem unterstützt COBOL auch gängige APIs wie RESTful.
Junge, innovative Communities für Mainframes begeistern
Stichwort Fachkräftemangel: Was sind die wichtigsten Maßnahmen, um Quereinsteiger, aber auch Studenten und Azubis, an die Themen Mainframe und COBOL heranzuführen?
Ein erster Schritt wären moderne Entwicklungsumgebungen auf Basis etablierter Plattformen wie Eclipse, Visual Studio und seit einiger Zeit auch Visual Studio Code. So fällt der Einstieg wesentlich leichter als mit altmodischen ISPF-Oberflächen.
Idealerweise beginnt die Beschäftigung mit dem Thema aber nicht erst beim Einstieg in ein Unternehmen, sondern bereits an der Hochschule. Hier sollten wir ein Bewusstsein für die immer noch vorhandene Bedeutung von COBOL schaffen, sodass wieder mehr Universitäten entsprechende Kurse anbieten. Micro Focus beispielsweise stellt Interessierten kostenfreie Lizenzen (zur privaten Nutzung) zur Verfügung, um die Einstiegshürde so niedrig wie möglich zu halten und den Erhalt von COBOL zu unterstützen.
Was müssten die Mainframe-Hersteller tun, damit ihre Plattformen langfristig relevant bleiben?
Diese Frage können wir als Software-Hersteller, der COBOL sowohl auf dem Mainframe unterstützt als auch auf Windows und Linux anbietet und unterstützt, nur bedingt beantworten. Aber gerade die aktuellen Initiativen, die Sie schon benannt haben (Open Mainframe, Zowe) zeigen, wo es hingehen kann. Mainframes müssen in aktuelle Infrastrukturen eingebunden werden und es muss gelingen, junge, innovative Communities für diese Technologie zu begeistern.
Dem Mainframe wird oft immer noch ein ausgesprochener Silo-Charakter attestiert. In Zukunft wird es auch darum gehen, dieses Denken in der Praxis zu widerlegen und aufzuzeigen, dass auch der Mainframe ein modernes interaktives System sein kann. Um relevant zu bleiben, müssen Mainframes natürlich auch aktuelle Anforderungen unterstützen. Hier ist IBM beispielsweise mit Watson und Blockchain-Unterstützung bereits sehr aktiv.
Sollen bestehende Mainframe-Systeme erhalten werden, muss immer auch deren Zukunftssicherheit gewährleistet werden können. Wir als Software-Anbieter sehen unsere Aufgabe primär darin, unseren Kunden einen Weg in die Zukunft zu ermöglichen – sei es durch Modernisierung oder durch Migration. Oft geht es aber auch gar nicht um eine solch binäre Entscheidung, sondern eher um ein schrittweises Vorgehen und eine behutsame Transformation.
Herr Reusch, vielen Dank für das Interview!
Im vorherigen Teil unserer Mainframe-Interviews haben wir uns mit Heidi Schmidt über ihre Meinung zu modernen Mainframe-Anwendungen unterhalten. Wolfram Greis sprach mit iX über die Karriere-Chancen im Mainframe-Kontext. Das Auftaktgespräch unserer Interview-Reihe haben wir über IBMs interne Sicht auf das Mainframe-Business geführt. ()
