Legacy Web-Applikation auf Container-Technologie umbauen – geht das?

Ihre Webapplikation wurde mit viel Geld und über viele Jahre entwickelt. Funktionell erfüllt sie die Bedürfnisse immer noch, aber die verwendete Technologie ist veraltet. Sie stehen vor der Entscheidung, die Applikation komplett neu entwickeln zu lassen. Sie haben wenig Zeit und Budget - und scheuen den Aufwand, den ein «Neubau» mit sich bringt.

Nexplore betreut für Kunden viele Webapplikationen über lange Zeitfenster von 5 bis 10 Jahren. Bei grösseren Technologiesprüngen stellt sich meist die Frage, Geld in eine Migration auf die Nachfolgetechnologie zu investieren – oder eine neue Applikation zu spezifizieren und zu entwickeln.

Bei einigen Projekten konnten wir mit der Migration auf eine containerbasierte Architektur die Laufzeit auf die nächste Technologiegeneration erreichen. Die Applikation kann einfacher in Module aufgeteilt und diese gezielt nach den wirtschaftlichen, funktionellen und technischen Bedürfnissen optimiert werden.

Was sind typische Auslöser?

Häufig stellt sich die Frage nach dem Umbau einer «Legacy Applikation» bei folgenden Fragestellungen:

Eine oder mehrere der eingesetzten Technologien haben das Lebensende erreicht. Die Lebensdauer der Applikation soll verlängert werden.
Es gibt Bereiche der Applikation, die besonders überlastet sind und skalierbar gemacht werden sollen. Das könnte beispielsweise das Modul für die Report-Generierung sein, wenn am Monatsende die Abrechnungen erstellt werden.
Sie möchten den Betreiber wechseln. Der neue Betreiber bietet Ihnen an, die Software in einem Container zu betreiben.
Sie möchten die Abhängigkeit vom Betreiber oder einem Hersteller verringern. Container und die Technologien der Cloud Native Computing Foundation basieren auf offenen Standards und ermöglichen es, die Software schnell und einfach auf einem anderen Cluster bei einem anderen Betreiber oder in der Public Cloud wie Microsoft Azure zu betreiben.

Beispiel einer Migration

Der Umbau lässt sich grob in die folgenden Schritte aufteilen:

Applikation auf containerbasierte Architektur umbauen - Schritt 1

Schritt 1 - Applikation container-fähig machen

Dieser Schritt ist bei älteren Applikationen meist sehr aufwändig. Wenn die Anwendung noch auf dem .NET-Framework 3.5 und den älteren Komponenten für Datenbankzugriffe basiert, dann müssen diese auf das aktuelle .NET Core Framework umgebaut werden.

Der Migrationspfad von Microsoft dafür ist steinig und führt häufig zum Neubau einiger Bereiche wie beispielsweise Datenbankabfragen oder Systemroutinen.

Das Web-Frontend wird möglichst separiert, damit getrenntePods für Backend-Logik und Frontend-Web-Applikation erstellt werden.

Das Ziel des Schrittes ist es, jeweils die bestehende Funktionalität 1:1 in einen Container zu übernehmen.

Das Ergebnis sieht beispielsweise so aus:

Die Applikationen für Frontend- und Backend sind getrennt und laufen jeweils in einem eigenen Pod.
Es laufen mehrere Pods der Applikation auf verschiedenen Servern («Nodes») des Kubernetes Clusters.

Applikation auf containerbasierte Architektur umbauen - Schritt 2

Schritt 2 - Aufteilen nach technischen Modulen

Danach kann die bestehende Monolith-Backend-Applikation in Module aufgeteilt werden. Das können beispielsweise nächtliche Verarbeitungsroutinen sein, oder für das Bereitstellen von API-Endpunkten.

Schritt 3 - Weitere Aufteilung, z.B. nach fachlichen Modulen

Im nächsten Schritt kann dann eine weitere Unterteilung nach fachlichen Themen wie beispielsweise fürs Personen-Verwaltung oder Buchhaltungsmodul erfolgen.

Hier ist es wichtig, eine passende Balance zu finden – zu viele Container und Module machen es komplexer und aufwändiger.

Probleme und Herausforderungen

Technische Probleme aufgrund der nötigen Migration auf .NET Core und Linux als Betriebssystem führen zu vielen Anpassungen. Diese müssen umfangreich getestet werden.

Auch die Datenmigration auf die neue Architektur und den Betrieb im Cluster ist deutlich aufwändiger.

Die Komplexität der Anpassung wird häufig unterschätzt. Termin und Budget werden zu knapp bemessen. Die technischen Umbauten sind oft sehr umfangreich. Infrastruktur und Betrieb auf der Containerplattform ist deutlich anders als klassisch in einer virtuellen Maschine oder einem Server. Dafür braucht es Zeit – auch beim Betreiber und den Fachverantwortlichen fürs Testen der fertigen Lösung.

Die Integration von Umsystemen muss geprüft und gegebenenfalls angepasst werden. Dazu gehört beispielsweise auch VPNs, Verschlüsselung mit SSL-Zertifikaten und Firewall-Regeln. Hier muss bereits sehr früh die neue Ziel-Architektur definiert werden, damit beim Aufspielen der Container später keine Verzögerungen auftreten.

Wichtig ist auch, die Verantwortlichkeiten beim Deployment und Betrieb klar zu definieren. Wer gibt die Freigabe fürs Einspielen der Release auf der Kundenumgebung? Wer ist zuständig, wenn ein Fehler oder ein Systemausfall auftritt?

Mit Kubernetes haben wir sogar die Möglichkeit, einen Monolith in einem Container zu betreiben.

Entscheidungsleitfaden

Entspricht die Anwendung den aktuellen und zukünftigen Anforderungen nicht mehr und ist technisch sehr veraltet, ist eine Neuentwicklung vermutlich die bessere Lösung.

Sind die Anforderungen aber noch erfüllt, sollte der Umbau auf Container geprüft werden.

Als containerisierte Applikation können die vielen Vorteile der Architektur genutzt werden. Dazu braucht es – abhängig von der Legacy Applikation – meist keinen teuren Totalumbau oder Neubau.

"Würde in Zukunft jede Applikation so betreiben" hören wir öfters. Die Software ist viel besser entkoppelt. Sie kann mit wenig Aufwand zu einem anderen Betreiber migriert werden.

Auch die einfachere Skalierung ist ein grosser Vorteil.