Migration von HOST-Anwendungen zu AWS: Modernisierung und Integration

Dieser Blog-Artikel beschreibt, wie man eine bestehende HOST-Anwendung in die Public Cloud migriert, unternehmenskritische Daten weiterhin auf dem Mainframe speichert und dem Kunden dennoch eine moderne, cloud-native Serverless-Anwendung zur Verfügung stellt.

Warum?

Legacy-Systeme sind nicht zwingend Altlasten, sondern vielmehr wertvolles Erbe. Diese Systeme sind häufig seit Jahren im Einsatz, erfüllen zuverlässig ihren Zweck, sind erprobt und haben für das Unternehmen einen hohen Business-Value. Viele dieser „Altanwendungen“ bestehen im Kern aus einer oder mehreren PL/I-Anwendungen auf dem IBM-Mainframe, wobei die Daten häufig über eine IBM Message Queue an den Host übertragen werden. Als User-Interface kommt eine klassische JSP-Anwendung zum Einsatz, die auf einem traditionellen WebSphere-Applikations-Server deployt ist.
Es gilt zunächst zu entscheiden, welche Teile der Altanwendung übernommen und welche neu entwickelt werden sollen. Unternehmen möchten, teilweise aus rechtlichen Vorgaben, die Datenspeicherung und -haltung nicht in die Hände der Cloud-Provider legen. Daher bleibt der Kern der Anwendung inklusive der Datenhaltung am Host, während die restlichen Komponenten in einer modernen, REST-basierten Cloud-native-Anwendung bei AWS neu entwickelt werden.

Serverless bei AWS  

Das Hauptziel der Neuentwicklung ist die Nutzung der Serverless-Dienste des Cloud-Providers. Zentrale Komponenten sind vor allem die AWS-Lambdas, die die Backend-Funktionalitäten für Serverless-Anwendungen darstellen. Da bisherige Anwendungen im Backend-Bereich sehr häufig mit Java EE bzw. Jakarta EE entwickelt werden, empfiehlt es sich, die Entwicklung der Lambdas mit dem Java-Framework Quarkus durchzuführen. Mithilfe sogenannter nativer Builds kann die Startgeschwindigkeit der Java-Anwendungen sogar beim Kaltstart der Lambdas signifikant reduziert und bestehender Business-Code übernommen werden.
Bei Nichtverwendung werden die Anwendungen beendet und nur bei Bedarf neu gestartet. Dies reduziert die Kosten und ermöglicht eine starke horizontale Skalierung. Als Frontend-Framework kommt, wie bei vielen modernen REST-basierten Anwendungen, Angular zum Einsatz. Die statischen Artefakte werden durch einen Build-Server, beispielsweise Jenkins, in einem S3-Bucket abgelegt. Die Auslieferung der Frontend-Anwendung erfolgt über CloudFront, einem Content Delivery Network (CDN).

Login-Aufrufe der Anwendung werden über ein API-Gateway zum Identity-Provider weitergeleitet, welcher bei korrekten Anmeldedaten ein Bearer-JWT (JSON-Web-Token) ausstellt. Dieses Token wird bei allen weiteren REST-Aufrufen im Authorization-Header mitgesendet, sodass die Backend-Services die Autorisierung überprüfen können.
Mithilfe des AWS-Services „Direct Connect“ wird eine dedizierte Verbindung zwischen AWS und dem On-Premise-Netzwerk, in dem sich der Host befindet, hergestellt. Die Benutzereingaben werden zunächst im Frontend überprüft und über ein API-Gateway an die Lambda übertragen. Hier können, wie im klassischen Backend, weitere Validierungen und Orchestrierungen durchgeführt werden. Anschließend werden die Daten über die direkte Verbindung an den Host übertragen und dort von den erprobten PL/I-Programmen verarbeitet und persistiert. Nach erfolgreicher Verarbeitung kann dem Benutzer beispielsweise ein PDF mit seinen erfolgreich verarbeiteten Daten mithilfe einer weiteren Lambda zum Download zur Verfügung gestellt werden.
Durch die Nutzung von Infrastructure as Code (IaC) mittels Terraform Enterprise kann die Provisionierung der AWS-Komponenten vereinfacht und revisionssicher gestaltet werden.

FAZIT

Der vorliegende Artikel zeigt auf, wie moderne AWS-Services in eine bestehende Host-Landschaft integriert werden können. Die Kosten, sowohl bei der Entwicklung als auch im Betrieb, sind dabei verhältnismäßig gering, da durch den Einsatz von Quarkus bestehendes Java-Know-how sowie Teile des Business-Codes wiederverwendet werden können. Durch die schnelle Ausführungszeit der Lambdas reduzieren sich die Kosten, da das Abrechnungsmodell von AWS Lambdas nur die Ausführungszeit berechnet.