WebSphere zu JBoss EAP migrieren: Was IT-Leiter vor dem Projekt wissen sollten

WebSphere läuft in vielen Unternehmen seit Jahren stabil. Trotzdem kommt irgendwann die Frage auf, ob die Plattform noch zum zukünftigen Betriebsmodell passt.

Auslöser können Kosten und Vertragsfragen sein. Ebenso eine anstehende Modernisierung, knappe Expertenkapazität oder der Aufwand, mit dem Releases, Änderungen und neue Umgebungen heute verbunden sind.

Ob ein finanzieller Business-Case entsteht, hängt vom konkreten IBM-Vertrag ab. Ebenso vom benötigten Red-Hat-Subscription-Umfang, der vorhandenen Infrastruktur und dem einmaligen Migrationsaufwand. Das lässt sich nur im Einzelfall rechnen.

Die wichtigere Frage lautet deshalb nicht nur: Welcher Application Server kommt danach? Sondern: Wie soll die Middleware danach betrieben werden?

Wer WebSphere zu JBoss migrieren will, sollte nicht nur den Application Server tauschen. Die Migration ist die Gelegenheit, JBoss EAP anschließend reproduzierbar, dokumentiert und weniger personenabhängig zu betreiben.

Das Zielbild vor der Migration festlegen

Der Schwerpunkt liegt auf dem späteren JBoss-Betrieb. Nicht auf einer ausführlichen Erklärung der bestehenden WebSphere-Architektur.

Vor der Migration muss entschieden werden, wo JBoss EAP künftig laufen soll. Und wie der spätere Betrieb aussehen soll.

Bei einer klassischen RHEL- oder VM-Plattform geht es darum, Installation, Konfiguration und Deployments reproduzierbar aufzubauen. Wenn OpenShift ohnehin kurzfristig das strategische Ziel ist, sollte geprüft werden, ob eine zusätzliche Zwischenmigration auf klassische VMs überhaupt sinnvoll ist. OpenShift ist dann kein späteres Add-on, sondern Teil der Zielentscheidung.

Die Leitfrage lautet: Wie sollen neue Stages aufgebaut, Konfigurationen geändert, Releases durchgeführt und Updates eingespielt werden, wenn die Migration abgeschlossen ist?

Aus der Antwort ergibt sich der Betriebsstandard, der während der Migration aufgebaut wird. Wer diese Frage erst nach dem Go-live stellt, übernimmt oft das bisherige, personenabhängige Modell und verschenkt den größeren Teil der Modernisierung.

Migration und Automatisierung gemeinsam denken

Hier liegt der eigentliche Hebel.

Für eine klassische JBoss-EAP-Plattform kann der definierte Sollzustand in Git liegen. JBoss EAP wird mit Ansible installiert und konfiguriert. Unterschiede zwischen Entwicklung, Test, Abnahme und Produktion werden kontrolliert über Konfiguration abgebildet. Server müssen nicht jeweils einzeln von Hand aufgebaut werden.

Ein Artifact Repository wie Artifactory oder Nexus stellt benötigte Artefakte kontrolliert bereit. Die Ansible-Ausführung kann über Red Hat Ansible Automation Platform erfolgen oder über eine vorhandene CI/CD-Infrastruktur.

Dabei geht es nicht darum, zuerst eine neue Toollandschaft aufzubauen. Was bereits vorhanden ist, wird genutzt. Fehlende Bausteine werden nur dort ergänzt, wo sie für einen reproduzierbaren Betrieb notwendig sind.

Das Ziel ist nicht möglichst viel Automatisierung. Das Ziel ist ein definierter Zustand, der sich über alle benötigten Umgebungen wiederholen lässt.

Wer WebSphere zu JBoss migrieren und den bisherigen manuellen Betrieb unverändert übernimmt, löst das Plattformthema. Die Abhängigkeit von Einzelwissen, die Unterschiede zwischen den Stages und der Aufwand bei jedem Release bleiben jedoch bestehen.

Typischer Migrationsweg

Ein belastbarer Weg sieht in der Praxis meist so aus:

1. Bestand aufnehmen und reduzieren. Welche Anwendungen, WebSphere-Versionen, Stages, Cluster und Abhängigkeiten existieren tatsächlich? Gleichzeitig prüfen, welche Anwendungen überhaupt noch migriert werden müssen. Nicht mehr benötigte Systeme abzuschalten ist oft der günstigste Teil einer Migration.
2. Migrationsfähigkeit analysieren. WebSphere-spezifische APIs, Deployment-Deskriptoren, Datasources, JNDI, Security, Messaging, Classloading und weitere Abhängigkeiten prüfen. Red Hats Migration Toolkit for Applications kann die technische Analyse unterstützen und typische Migrationsstellen sichtbar machen.
3. Zielbild definieren. JBoss-EAP-Version, RHEL/VM oder OpenShift, Stages sowie Betriebs- und Automatisierungsstandard festlegen.
4. JBoss reproduzierbar aufbauen. Installation und Konfiguration automatisieren und stage-spezifische Unterschiede sauber abbilden. Git, Artifact Repository und Ansible-Ausführung in den Prozess integrieren.
5. Anwendungen schrittweise migrieren und testen. Notwendige Anpassungen vornehmen, technische und fachliche Tests durchführen und Produktivsetzung sowie Rückfallweg planen.
6. Betrieb übergeben. Monitoring, Release- und Update-Prozesse, Dokumentation und Automatisierung in den Regelbetrieb überführen und Wissen an das Kundenteam übertragen.

Die Migration ist erst dann fertig, wenn nicht nur die Anwendung läuft. Das Kundenteam muss die neue Plattform beherrschen.

Wer JBoss EAP 7 noch im Bestand hat oder den Support-Status der Zielversion klären muss, sollte das vor der Festlegung des Zielbilds prüfen.

Aus der Praxis

Bei einem IT-Dienstleister in einem regulierten Umfeld sollte eine bestehende Unternehmensanwendung von WebSphere auf JBoss EAP umziehen. Es gab mehrere Stages. Das bisherige Betriebsmodell war gewachsen und stark von einzelnen Personen abhängig. Eine 1:1-Übertragung auf JBoss hätte denselben Zustand nur auf einem anderen Application Server fortgesetzt.

Der kritische Moment kam bei der ersten Bestandsaufnahme der Zielumgebungen. Dev, Test und die vorgesehene Produktionslinie unterschieden sich in Konfiguration, Deployment-Weg und implizitem Sonderwissen. Eine reine Anwendungsverschiebung hätte diese Unterschiede mitgenommen. Jede spätere Änderung wäre wieder zum Einzelprojekt geworden.

Die Entscheidung lautete deshalb: Nicht nur die Anwendung migrieren. Parallel JBoss-Installation, Konfiguration und Deployment mit Ansible standardisieren. Der Sollzustand sollte nachvollziehbar und über die Stages wiederholbar sein.

Nach der Migration existierte nicht nur eine funktionierende JBoss-Plattform. Automatisierung, Dokumentation, Monitoring, Release-Unterstützung, Wissenstransfer und Betriebsübergabe waren Bestandteil des neuen Betriebsmodells. Der nachhaltige Nutzen entstand nicht allein durch den Wechsel des Application Servers. Er entstand dadurch, dass der spätere Betrieb gleichzeitig neu geordnet wurde.

Fazit

Eine WebSphere-zu-JBoss-Migration ist kein reiner Austausch des Application Servers. Kosten können das Projekt auslösen. Sie müssen aber im Einzelfall gerechnet werden.

Der größere Hebel liegt häufig darin, die Migration zu nutzen, um einen wiederholbaren JBoss-Betrieb aufzubauen. Konfigurationen werden nachvollziehbar. Umgebungen werden reproduzierbar. Wissen lässt sich besser an das Betriebsteam übergeben.

Wer WebSphere nur durch JBoss ersetzt und den bisherigen manuellen Betrieb übernimmt, verschenkt einen großen Teil der Modernisierung.