Großrechner virtualisiert und in die Cloud migriert

Swisscom schickt seine Mainframes in Rente

| Autor: Ulrike Ostler

Ein historischer Moment: Werner Pfäffli schaltet im April 2019 den Mainframe von Swisscom in Bern aus. Die Großrechnerepoche bei dem Telekommunikationsdienstleiter ist beendet.
Ein historischer Moment: Werner Pfäffli schaltet im April 2019 den Mainframe von Swisscom in Bern aus. Die Großrechnerepoche bei dem Telekommunikationsdienstleiter ist beendet. (Bild: Swisscom)

Der Schweizer Telekommunikationsanbieter Swisscom hat seine Mainframe-Anwendungen auf x86-Plattformen unter Red Hat Linux migriert, ohne die Kernanwendungen zu verändern. Die Workloads laufen nun in der unternehmenseigenen Cloud und kosten im Betrieb nur noch die Hälfte. Markus Tschumper, Head of General IT Services der Swisscom, erläutert, wie das möglich ist.

Dale Vecchio ist heute Chief Marketing Officer bei LzLabs, Anbieter des „Software Defined Mainframe“, einer Technik, die Großrechner-Datenbank und -Logik kapselt, um diese auf x86-Plattformen portieren zu können. Früher war er bei Gartner, zuständig für den Bereich Mainframe; insgesamt verfügt er über rund 40 Jahre Großrechner-Know-how. Er sagt: „Bis jetzt kannte ich kein Unternehmen, das seine komplette Mainframe-Workloads auf x86 migriert hat - ohne Änderungen im Code“, etwa durch Compilieren. Genau das hat Swisscom bewerkstelligen können.

Zu teuer, zu unhandlich

Vecchios Ausführungen portieren andere Mainframe-Nutzer einzelne Anwendungen oder ändern den Code und schaffen die ursprüngliche Anwendung ab. Und dafür gebe es drei Gründe: Kosten – Mainframe-Computing selbst, die -Tools und das -Know-how sei teuer – die fehlenden Skills – Frauen und Männer, die sich mit Mainframes auskennen, seien rar gesät beziehungsweise in Rente – und fehlende Agilität – es sei schwierig, die Anwendungen mit einer langen Entstehungsgeschichte auf neue Anforderungen anzupassen. Im Fall von Swisscom, einem 20.000-Mitarbeiter-Unternehmen mit 12 Milliarden Franken Umsatz (10,6 Milliarden Euro) und 1,5 Milliarden Franken (rund 1,3 Milliarden Euro) Gewinn, war der Mainframe-Betrieb in zunehmendem Maß zu teuer.

Die Mainframe-Historie der Swisscom reicht lange zurück: Auf diesem Bild schaltet im Sommer 1990 Werner Pfäffli einen Mainframe bei der “Schweizer Post” (PTT) an
Die Mainframe-Historie der Swisscom reicht lange zurück: Auf diesem Bild schaltet im Sommer 1990 Werner Pfäffli einen Mainframe bei der “Schweizer Post” (PTT) an (Bild: Swisscom)

Insgesamt handelt es sich um drei große Anwendungen, die auf dem Mainframe zuhause und mit dem Attribut „geschäftskritisch“ versehen waren: ein Billing-System für die Festnetzsparte der Swisscom, eine Verwaltungs- und Inventarisierungs-Anwendung für das analoge Netz sowie eine zentrale Nummernverwaltung. Zugehörig waren 14 externe Systeme wie Auftragsverwaltung, Traffic-Analysen, geografische und Adressinformationen, Data Warehousing, Telefon- und Netzverwaltung. Das wiederum mündete in 50 Transaktionen pro Sekunde, rund 100.000 „IMS“-Transaktionen und mehrere Millionen SQL-Statements pro Tag.

Die einzelnen Anwendungsteile sind in hauptsächlich in Cobol und PL/1 geschrieben; dazu kommen Java Stored Procedures. Swisscom nennt 3.850 einzelne PL/1-Programme (V3/V4) inklusive 36 Assembler-Routinen, insgesamt 1,5 Millionen Codezeilen und 1.058 Cobol-Programme (V2/V3) mitsamt einigen C- und Assembler-Applikationen, rund 1,7 Millionen Codezeilen. Dazu kommen 12.200 plus 20.000 SQL-Statements; denn die Anwendungen waren per „DRDA“-Verbindungen mit dem Relationalen Datenbank Management System „DB2“ verknüpft.

3,2 Millionen Lines of Code

Die Anwendungen nutzten den „IMS Transaction Manager“ (IMS/TM), um mit anderen Anwendungen per „MQ“-Messages kommunizieren zu können. Zugrunde lag die Message-orientierte Middleware „Websphere MQ“.

Die Anwendungen gehörten zu den ältesten im Unternehmen, führt der Chef der allgemeinen IT-Services bei Swisscom, Markus Tschumper, aus, das Programm „Telefonrationalisierung mit Computern“, etwa aus den 70er Jahren. Klar, dass es diverse Überarbeitungen gab. Vor zwei Jahren diskutierte man bei Swisscom schließlich final darüber, ob und wenn ja wie die Mainframe-Applikationen abgelöst werden sollten. „Der signifikante Punkt“, so Tschumper“ waren die Kosten.

Einen Benchmark im Vergleich zu ähnlichen Anwendungen in derselben oder vergleichbaren Branchen hat das Telco-Unternehmen nicht gemacht. Allerdings rechnete Swisscom aus, welcher Kostenblock in der IT zu hoch erschien und mit ein, dass es zunehmend schwer war, Mainframe-Leute auf dem Markt zu finden. „Es war die Konstellation aus teurer Hardware, der Lizenzierung von Spezial-Tools und der ausdünnenden Manpower – unsere Mitarbeiter waren in den Umfeld 50, 60 Plus Jahre alt“, erläutert Tschumper.

Markus Tschumper ist Head of General IT Services der Swisscom.
Markus Tschumper ist Head of General IT Services der Swisscom. (Bild: Ulrike Ostler/Vogel IT-Medien GmbH)

„Die Mainframe-Anwendungen liefen stabil und super performant“, setzt er hinzu. Außerdem hätten sich die Mitarbeiter durch einen, im positiven Sinn Stolz auf den Beitrag, den sie zum Erfolg des Unternehmens leisteten, ausgewiesen. „Zurecht“, wie er sagt. Dennoch habe es keine Alternative zur Abkehr vom Mainframe-Computing gegeben.

Allerdings seien verschiedenen Optionen des „Wie?“ durchgerechnet worden. Da die Margen im Festnetz beziehungsweise analogen Umfeld schwinden und sich die Services nicht ganz so dynamisch entwickeln, wie im digitalen und im Funknetz, wäre zum Beispiel eine Standard-Software denkbar gewesen? Tschumper verneint: „Die Telco-Anwendungen haben sich über 50 Jahre entwickelt und weisen deshalb eine Menge an Spezialfunktionen auf.“ Deshalb sei das Einführen einer Standard-Software „schwierig“.

Laut Ex-Gartner-Analyst Vecchio ist aber auch das Risiko des Scheiterns bei der Alternative Neucodierung extrem hoch. Zum einen würden Funktionen und Features existenter Anwendungen nachgebaut. Da aber Programmteile und Aufrufe von Subroutinen in den bestehenden Anwendungen in ihrer Existenzberechtigung durchaus fraglich seien, führte das zu Konflikten. „Die Anwender wollen das Bekannte, selbst wenn dieses nicht viel taugt“, so Vecchio.

Schlechte Erfahrungen mit Migration plus Prozess-Re-Engineering

Tatsächlich verneint Tschumper die Frage, ob ein Prozess-Re-Engineering erfolgt sei, also eine Überprüfung, ob die Prozesse, wie sie vorliegen sinnvoll sind oder neu definiert gehören. „Aufgrund unserer bisherigen Erfahrungen“, haben wir das nicht gemacht“, sagt der Chef der General IT-Services.

LzLabs verspricht mit seinem „Software Defined Mainframe“, dass keine Änderungen am Ursprungscode notwendig würden, wenn ein Kunde sich zu dieser Form der Migration entschließe. Um es vorweg zu nehmen: Statt auf DB2 liegen die Daten jetzt auf einer quelloffenen „Postgres“-Datenbank und die Anwendungen laufen auf x86-Rechnern in der unternehmenseigenen Cloud unter einem Linux-Derivat von Red Hat. Während des zweijährigen Migrationsprojekts, das im April dieses Jahres abgeschlossen wurde, zogen rund 20 Terabyte an Mainframe-Storage auf Postgres um. Die Großrechner sind abgeschaltet.

Thilo Rockmann ist Chairman and COO von LzLabs, Hersteller des "Software Defined Mainframe".
Thilo Rockmann ist Chairman and COO von LzLabs, Hersteller des "Software Defined Mainframe". (Bild: Ulrike Ostler/Vogel IT-Medien GmbH)

Thilo Rockmann, Chairman and COO von LzLabs, erläutert grob, wie das funktioniert. „SDM bildet quasi eine Schicht zwischen der Anwendung und den neuen Plattformen, Linux plus x86 sowie Postgres.“ Somit sei es unnötig, die Datenformate oder die Anwendungslogik zu ändern. Er sagt: „Rund 80 Prozent der Programme bestehen aus der Kommunikation mit dem Betriebssystem“. Das aber erledige SDM. Lediglich bei einem geringen Prozentsatz der Aufrufe von Unterprogrammen oder Routinen beziehungsweise weiteren Anwendungen sei ein Echtzeitkompilieren notwendig.

Die Projekt-Phasen

Damit das funktionieren kann, haben Swisscom und LzLabs zunächst ein Proof-of-Concept aufgesetzt. Dann folgte die „Discovery“-Phase:

  • Wo liegen die Daten?
  • Welche Systeme greifen wie darauf zu?
  • Welche Untersysteme werden aufgerufen?
  • Welche Verbindungen bestehen zu anderen Systemen?
  • gehörten zu den Fragen, die vorab geklärt werden mussten.
  • Welche Use-Cases werden benötigt und wie lassen sich diese, möglichst automatisiert testen?

Danach ging es an das Architektur-Design, dann zur Umsetzung, zum Testen und zum Going Life, mitsamt eines ersten Testlaufs: noch nicht mit allen Daten, für 2,5 Monate, in abgespeckter Form. Ein Parallelbetrieb von Mainframe- und Cloud-Anwendungen war jedoch ausgeschlossen, da einige Daten nur ein einziges Mal vorkommen dürfen.

In der „heißen Phase der Migration“ waren auf der Swisscom-Seite rund 100 Mitarbeiter involviert, 20 davon in Vollzeit. Auf der LzLabs-Seite arbeitete ein Dutzend für den Erfolg.

Jetzt sind bei Swisscom noch zwölf Mitarbeiter für die SDM-Anwendungen zuständig und gemeinsam mit LzLabs sollen noch weitere Anpassungen erfolgen. Dafür könnten jetzt neue Services direkt auf der Postgres-Datenbank, unterhalb des SDM-Layers realisiert werden, beschreiben die Projektverantwortlichen von LzLabs und Swisscom einen der Vorteile der neuen Plattformen.

Sowohl die OPEX- als auch die CAPEX-Ausgaben der Swisscom-IT sinken und damit werden über einen Zeitraum von zwei Jahren nach der Migration zu LzLabs "Software Defined Mainframe" Kosteneinsparungen möglich.
Sowohl die OPEX- als auch die CAPEX-Ausgaben der Swisscom-IT sinken und damit werden über einen Zeitraum von zwei Jahren nach der Migration zu LzLabs "Software Defined Mainframe" Kosteneinsparungen möglich. (Bild: LZLabs)

Günstig war die Migration nicht; laut Tschumper belaufen sich die Projektkosten auf einen Millionenbetrag. Doch das dürfte verschmerzbar sein; denn die Kosten für den Betrieb der Anwendungen werden sich um etwa dieses Summe halbieren: Der IT-Manager kommt auf:

  • 70 Prozent Einsparung bei der jährlichen wiederkehrenden Core-Software-Lizenz
  • 25 Prozent Einsparung bei anderer Software, wobei der Schwerpunkt auf dem Einsatz von Open-Source anstelle von ISV-Software liegt.
  • Eine Reduktion der IT-Gesamtkosten im Vergleich zu früheren Mainframe-Ausgaben von 50 bis 60 Prozent. Eingerechnet sein die höheren Ausgaben für Security sowie die Umlagen aus dem Cloud-Betrieb.

Der Wandel

Umgekehrt hat es Lzlabs bei Swisscom das erste Mal mit der Transaktions-Middelware IMS/TM zu tun gehabt. Diese individuelle Anforderung gehe jetzt jedoch in das Standard-Angebot des Softwarehauses ein, so Vorstand Rockmann. Ansonsten sorgten moderne Container-Technologien wie Docker, Ansible und Kubernetes dafür, dass SDM portierbar bleibe.

Swisscom-Manager Markus Tschumper hat heute gut lachen: SDM spart Millionen.
Swisscom-Manager Markus Tschumper hat heute gut lachen: SDM spart Millionen. (Bild: Ulrike Ostler/ Vogel IT-Medien GmbH)

„Mit der Mainframe-Ablösung geht ein tiefgreifender kultureller Wandel einher“, führt Swisscom-Manager Tschumper aus. Für das Change-Management hatte das Mainframe-Team einen Coach. Er selbst habe jedoch auch auf dem „heißen Stuhl“ gesessen und zu den anstehenden Änderungen Rede und Antwort stehen müssen.

„Solche Veränderungen laufen immer gleich ab“, führt er heute aus. „Zuerst kommt das Verneinen, dann die Resignation und schließlich die Akzeptanz.“ Tatsächlich seien noch Ex-Mainframer im Haus, so der Manager.

Mainframes dagegen gibt es bei Swisscom nun gar nicht mehr: Zwei Z-OS-Systeme im Sysplex-Betrieb hatte das Telco-Unternehmen mit rund 2.500 MIPS im Einsatz. Einen Rechner schenke die Company der Hochschule in Luzern, der andere ist ausgeräumt und beheimatet heute einen Kühlschrank inklusive SAT-Anlage.

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 45926302 / Virtualisierung)