Business-IT
27.01.2017
Software-defined Mainframe im Container
1. Teil: „So soll der Großrechner überflüssig werden “

So soll der Großrechner überflüssig werden

MainframeMainframeMainframe
Fotolia / Alexandr_Mitiuc
LzLabs überträgt COBOL- und PL/1-Programme ohne Rekompilierung auf x86-Umgebungen beziehungsweise Cloud-Plattformen. Damit wandert der Mainframe in die Cloud.
Wer glaubt, die große Zeit der Mainframes sei längst vorbei, der irrt. Laut dem US-Unternehmen Vanguard Integrity Professionals, das unter anderem Security-Audits für verschiedene Plattformen anbietet, liegen immer noch 70 Prozent aller Geschäftsdaten auf Großrechnern. Und bei 71 Prozent der Unternehmen auf der Fortune-500-Liste läuft Vanguard zufolge das Kerngeschäft nach wie vor über Applikationen auf
z/OS-Systemen.
  • Quelle: Vanguard Integrity Professionals
Ein Trend weg vom Mainframe sei nicht zu erkennen, sagt John Abbott, Infrastructure Analyst bei 451 Research: „Großrechner gibt es seit 50 Jahren – und es wird sie auch in 20 Jahren noch geben.“
Nach Ansicht von Andreas Thomasch, Mainframe-Leader bei IBM, hat die nach wie vor bestehende Beliebtheit des Großrechners gute Gründe: „Mainframes sind unerreicht in den wesentlichen IT-Betriebskriterien Sicherheit, Verfügbarkeit und Skalierbarkeit der Plattform.“ Dieses Bekenntnis zum Großrechner ist verständlich, schließlich ist IBM unumstrittener Marktführer im Mainframe-Geschäft. Mit dieser Ansicht ist IBM aber nicht allein. Auch andere Unternehmen sehen das so – etwa der Software-Anbieter BMC, der unter anderem Managementlösungen für Mainframes vertreibt: „Moderne Großrechner können bis zu 2,5 Milliarden Transaktionen am Tag verarbeiten, rund um die Uhr. Auch die heutigen Forderungen nach zentralisierten, virtualisierten und hochgradig automatisierten Umgebungen erfüllt der Mainframe seit Jahren; dazu ist er stabil und ausgereift“, sagt Geschäftsführer Uwe Behley.
Andere Marktteilnehmer halten Großrechner dagegen vor allem für eines: riesige Geldvernichtungsmaschinen. Bis zu 90 Prozent der operativen Kosten könne man sparen, wenn man seine Mainframe-Plattform in Rente schickt, verspricht der IT-Dienstleister CGI. Etwas moderatere Zahlen nennt Hewlett Packard Enterprise. Das Unternehmen rechnet mit einer Reduktion der Gesamtbetriebskosten (Total Cost of Ownership, TCO) von 50 bis 70 Prozent. BMC-Chef Behley hält solche Zahlen für unbewiesen: „Wo ist etwa dargelegt, dass die Kosten eines Neusystems von bis zu 2,5 Millionen Euro einem adäquaten 4000-Mips-Rechner technisch gleichwertig sind?“

Alternativen zum Mainframe

Kosten sind nach Ansicht von John Abbott jedoch gar nicht der entscheidende Faktor, wenn Unternehmen sich für die Migration von Mainframes auf x86-Umgebungen oder in die Cloud entscheiden: „Es geht viel mehr um Flexibilität und um die Möglichkeit, schnell auf Marktveränderungen reagieren zu können“, sagt der Analyst. Zudem werde es immer schwieriger, fachkundiges Personal für die Betreuung und Weiterentwicklung von Mainframe-Applikationen zu finden.
In den vergangenen Jahren gab es deshalb etliche Bestrebungen, die meist in COBOL oder PL/1 geschriebenen Großrechneranwendungen auf andere Systeme zu portieren. Schon lange bekannt sind Emulatoren, die Mainframe-Betriebssysteme in einer x86-Umgebung nachbilden. Laut IBM ist die Emulation aber nur für Trainings- und Wartungszwecke sinnvoll: „Für Mission Critical ist so etwas nicht geeignet“, sagt Thomasch. Eine weitere Möglichkeit ist das Mainframe-Rehosting, das heißt eine Portierung von Mainframe-Applikationen auf Linux-, Windows- oder Unix-Systeme. In der Regel ist dazu ein Rekompilieren der Anwendung nötig.
Weitere Ansätze sind das Mainframe-Outsourcing oder das Übersetzen des Quellcodes in einen x86-kompatiblen Dia­lekt beziehungsweise eine andere Programmiersprache. Viele Migrationsprojekte seien in der Vergangenheit allerdings misslungen, sagt Thilo Rockmann, Chairman und COO von LzLabs: „Meist sind sie daran gescheitert, dass die Applika­tion neu gebaut und im Kern verändert werden musste, denn dies erfordert eine tiefe Kenntnis der Applikation, allein um bestehende Funktionalitäten nachzubilden.“
Das Schweizer Start-up will deshalb ganz ohne Anpassung des Quellcodes auskommen. „Das Ziel ist, Applikationen die in COBOL oder PL/1 für einen z/OS-Mainframe geschrieben sind, in einer x86-Linux-Umgebung beziehungsweise auf einer Cloud-Plattform lauffähig zu machen, ohne sie neu kompilieren zu müssen“, erklärt Rockmann.
Das Unternehmen hat dazu ein Software-defined Mainframe (SDM) genanntes Container-System entwickelt. Mit seiner Hilfe lassen sich Anwendungen vom Großrechner auf Intel-basierte Server übertragen. Selbst auf Geräten mit ARM-Prozessoren wie dem Rasp­berry PI ist das System lauffähig – allerdings wird die Plattform derzeit nur zu Testzwecken genutzt und nicht offiziell unterstützt. Als Betriebssystem kommt Red Hat Enterprise Linux (RHEL) zum Einsatz.
2. Teil: „Der schwierige Weg zum SDM“

Der schwierige Weg zum SDM

Man nehme eine Applikation und packe sie in einen Container – was sich so einfach anhört, ist beim Transfer von Mainframe-Anwendungen in die Open-Systems-Welt alles andere als trivial. Das beginnt schon bei der Speicheradressierung. Z Systems, die Großrechnerarchitektur von IBM, speichert das höchstwertige Bit zuerst (Big-Endian), während x86-Prozessoren das Little-Endian-Format nutzen, also mit dem kleinstwertigen Bit beginnen.
Auch beim Zeichensatz gehen Mainframes ihre eigenen Wege. Statt ASCII (American Standard Code for Information Interchange) wird EBCDIC (Extended Binary Coded Decimal Interchange Code) verwendet, dessen Konzept noch aus Zeiten der Lochkartenkodierung stammt und bei dem, anders als bei ASCII, die Buchstaben A bis Z nicht lückenlos aufeinanderfolgen.
Ganz zu schweigen von Mainframe-Spezialitäten, etwa hierarchischen Datenbanken wie IMS/DB (Information Management System/Data Base), Zugriffsmethoden wie VSAM (Virtual Sequential Access Method) und BSAM (Basic Sequential Access Method), Transaktionsmanagern wie CICS (Customer Information Control System) oder dem IMS/TM (Information Management System/Transaction Manager) sowie Security-Umgebungen wie ACF2 (Access Control Facility) oder RACF (Resource Access Control Facility).
Kein Wunder also, dass LzLabs einige Zeit brauchte, um all diese Komponenten und Subsysteme in einer x86-Umgebung nachzubilden.
Erst zur CeBIT 2016 stellte das bereits 2011 gegründete Unternehmen sein Produkt vor, der offizielle Start erfolgte im Juli dieses Jahres. Noch sind nicht alle Spezialfälle der Mainframe-Welt abgedeckt, gibt Thilo Rockmann zu: „Wir haben uns nach der 80-20-Regel erst einmal auf die Themen konzentriert, wo wir die größte Nachfrage vermuten. Es wird aber noch ein bis anderthalb Jahre dauern, bevor wir in
einem Gros der Fälle weitgehend automatisiert migrieren können.“
Derzeit unterstützt LzLabs COBOL-Programme, relationale Datenbanksysteme, das CICS-Transaktionsmanagement sowie VSAM. In den nächsten Monaten sollen auch hierarchische Datenbanken und PL/1-Anwendungen im Software-defined Mainframe laufen können. Auch das IMS-Transak­tionsmanagement soll dann unterstützt werden.
Neben einer Kooperation mit Red Hat, die auch gemeinsame Marketingaktivitäten umfassen soll, arbeitet der Hersteller eng mit Microsoft zusammen, um den SDM in die Cloud zu bringen. LzLabs ist Mitglied des „BizSpark“-Programms, in dem Microsoft Start-ups für drei Jahre Werkzeuge, Software und Cloud-Services unentgeltlich zur Verfügung stellt. Aufgrund der spezifischen Anforderungen wurde LzLabs für das „BizSpark Plus“-Programm nominiert, das einen erweiterten Zugriff auf Azure-Cloud-Services erlaubt.
„Aus meiner Sicht bietet die Software-defined-Mainframe-Lösung von LzLabs einen einmaligen Lösungsansatz“, sagt Beat Schuppli, Business Development Manager bei Microsoft. Neben der technischen Unterstützung hilft Microsoft dem Neuling auch bei der Marktbearbeitung. „Ziel für Microsoft ist es, aus einer solchen Zusammenarbeit den Lösungs-Partner erfolgreich im Markt zu positionieren oder noch erfolgreicher zu machen“, so Schuppli weiter.

Die Vorteile des SDM

Laut Thilo Rockmann bietet der Software-defined Mainframe gegenüber dem Mainframe-Betrieb Einsparpotenziale von 85 bis 90 Prozent. Berücksichtige man die Migrationskosten, ließe sich ein Return on Invest in ein bis zwei Jahren erzielen. Die Umstellung selbst soll in wenigen Monaten abzuschließen sein. „Die eigentliche Mi­gration geht relativ schnell vonstatten und ist nicht sehr aufwendig“, sagt der LzLabs-COO. Einwände der Kritiker, die Mainframe-Performance sei unerreicht und könne nur mit hohen Hardware-Investitionen kompensiert werden, lässt Rockmann nicht gelten: „Intel-Systeme sind dem Mainframe mindestens ebenbürtig, wenn nicht sogar überlegen.“
Das Aufmerksamkeit sei vor allem im Bereich Banken und Versicherungen enorm groß. „Egal wo wir hinkommen, sind die Kunden hoch interessiert“, erklärt Rockmann. Die Kosten für die Mainframe-Umgebungen würden aus dem Ruder laufen und lägen bei großen Banken im dreistelligen Millionenbereich, so Rockmann weiter. „Der Druck ist spürbar, man sucht überall händeringend nach Lösungen.“
Von den Finanzdienstleistern abgesehen sieht LzLabs weiteres Kundenpotenzial im Handel, bei Service-Providern, Behörden oder in der Automobilindustrie. „Typischerweise sind unsere Kunden sehr lange existierende, große Unternehmen“, sagt der COO.
3. Teil: „Die Pläne von LzLabs“

Die Pläne von LzLabs

Um andere Märkte angehen zu können, will das Unternehmen vor allem mit Partnern wie Systemintegratoren, Beratungsunternehmen oder Service-Providern zusammenarbeiten. LzLabs konzentriert sich weitgehend auf das Bereitstellen der Infrastrukturen, die Migration sollen Partner übernehmen. Man selbst habe keine Pläne, in das Consulting-Geschäft einzusteigen, sagt Rockmann. „Wir verstehen uns als Software-Firma und wollen das auch bleiben.“
Dass die Übertragung bestehender Applikationen nur ein erster Schritt sein kann, ist wohl auch LzLabs klar. Nicht umsonst hat das Unternehmen im Ok­tober vergangenen Jahres den Software-Entwickler Eranea übernommen. Dieser bietet eine Entwicklungsumgebung an, die COBOL-Code größtenteils automatisiert in Java überträgt. „Mit den Einsparungen aus dem Transfer lassen sich die Kosten für die Modernisierung einer Applikation gegenfinanzieren“, sagt Rockmann.
Kritik am SDM-Konzept
IBM hält naturgemäß wenig vom SDM-Ansatz: „Die Migra­tion von Mainframe-Anwendungen ist in vielen Fällen nicht sinnvoll, gerade dann, wenn es um hochskalierbare Mission-Critical-Aufgaben geht“, sagt Andreas Thomasch. Ein technischer Plattformwechsel führe Kunden nicht zwingenderweise zu mehr Wettbewerbsfähigkeit, sondern über erhebliche Investitionen und Risiken nur zu einer neuen Umgebung mit der gleichen Funktionalität wie zuvor. „Wo liegt da der Mehrwert?“, fragt der Mainframe-Experte.
Auch die Aussage, Großrechner stünden agilen Konzepten und einer Cloud-Strategie im Weg, will er nicht stehen lassen: „Viele Mainframes werden de facto als hochsichere und -verfügbare Cloud in den Rechenzentren der Kunden betrieben. Diese Systeme teilen sich virtualisierte CPUs, Speicher und IO-Anbindung, lassen sich in wenigen Minuten über dynamische Subsysteme provisionieren und skalieren, gleichen Lastspitzen über On-Demand-Fähigkeiten aus und sind granular abrechenbar.“
BMC-Geschäftsführer Behley betont vor allem die Leistungsfähigkeit und Stabilität von Großrechenanlagen: „Alle Nicht-Mainframe-Systeme bringen ein wesentliches größeres Risiko mit sich – nicht nur bei der Transaktionssicherheit, sondern auch bei der Performance und vor allem beim Thema Datensicherheit“, warnt er.
Fazit
Das Konzept von LzLabs erscheint vielversprechend. Zumindest kleinere Applikationen mit einem überschaubaren Funktionsumfang lassen sich extrem schnell und ohne Anpassungen am Quellcode auf x86-Systeme oder in die Cloud übertragen. Das hat LzLabs bereits eindrücklich bewiesen. Noch fehlen allerdings Referenzen und Erfahrungen aus großen Kundenprojekten, die den Nutzen des Software-defined-Mainframe-Konzepts unter realen Bedingungen demonstrieren.
Das größte Risiko für das Geschäftsmodell von LzLabs kommt aber von einer anderen Seite: „IBM reagierte in der Vergangenheit auf Bedrohungen seines Mainframe-Geschäfts mit rechtlichen Schritten oder kaufte die Technologie auf, um sie dann aus dem Markt zu nehmen“, so 451-Research-Analyst Abbott.

mehr zum Thema