App in die Cloud mit Java EE

Inhaltsverzeichnis

Obwohl die Programmiersprache Java zu einer Zeit entstand, als das Internet noch in den Kinderschuhen steckte und der Begriff Cloud Computing noch längst nicht existierte, bietet es sich an, Java-Anwendungen in die Cloud zu migrieren oder dort neu zu entwickeln. Dieser Artikel betrachtet die Möglichkeiten dafür jenseits des Rehostings von On-premises-Anwendungen in die Cloud (Lift & Shift) und zeigt auf, welche Dienste von AWS (Amazon Web Services) für eine Cloud-native-Entwicklung zur Verfügung stehen. Mit einer eigenen kostenlosen Linux- und Java-Distribution bietet Amazon eine gute Basis.

Überblick verschaffen und Angebot sichten

Wie bei jeder guten Reisevorbereitung gilt es, die eigenen aktuellen Anforderungen und Ressourcen zu sichten und sich einen schnellen Überblick über mögliche Angebote zu verschaffen. Erst dann lässt sich eine entsprechende Strategie und Planung erstellen. Um den Zustand einer zu migrierenden Anwendung sowie das Risiko und die Chance einer Modernisierung einzuschätzen, gibt es verschiedene Code-Metriken, um die "Cloud-Readiness" einer Anwendung zu bestimmen.

Dafür lässt sich der auf dem Code-Such- und Transformationssystem OpenRewrite basierende, kostenlose Cloud Suitability Analyzer von VMware verwenden. OpenRewrite definiert Regeln, um zu prüfen, welche Stellen durch ein Update der Java-Version oder einer Spring-Boot-Version betroffen sind. Einige der nötigen Anpassungen kann OpenRewrite automatisch durchführen, während man andere erst nach mehreren Tests feststellen wird – um schließlich alle 12-Faktor-App-Kriterien für eine Cloud-native App nach der Definition der Cloud Native Computing Foundation (CNCF) zu erfüllen. Hilfreich ist es, dafür automatische Builds oder das Spring-Cloud-Framework einzusetzen. Die Spring-Cloud-AWS-Erweiterungen vereinfachen die Verwendung und damit die Integration der Anwendung in einige AWS-Dienste.

Diese Optionen bietet AWS

Möchte man eine typische Java-EE-Webanwendung in die AWS-Cloud bringen, gibt es dafür mehrere Dienste. Welche man verwendet, hängt vom vorhandenen Wissen über AWS sowie von der gewünschten Flexibilität ab. Die einfachste Möglichkeit, eine Java-EE-Webanwendung ohne viele Änderungen in die AWS-Cloud zu bringen, ist der Orchestrierungsdienst AWS Elastic Beanstalk. Er basiert auf den virtuellen Amazon-Elastic-Compute-Cloud-(EC2)-Instanzen mit einem Amazon-Linux-Image (AL2023). Es ist lediglich der gewünschte Instanztyp mit einem passenden Amazon Machine Image (AMI) mit Linux oder Windows auszuwählen.

Elastic Beanstalk richtet die notwendigen Netzwerke und Lastverteiler ein, ohne dass Entwicklerinnen und Entwickler sich mit den dahinterliegenden AWS-Diensten näher beschäftigen müssen. Sie können einfach ihre Datenbank in einer verwalteten Amazon-RDS-Datenbank (MySQL, MariaDB, PostgreSQL, Oracle, SQL-Server) anlegen und ihre Anwendung wie gewohnt als WAR-Datei in einen Apache-Tomcat-Webserver deployen. Insgesamt gibt es ein breites Spektrum an Compute- und relationalen Datenbank-Diensten bei AWS, bei der die Auswahl zwischen Komfort und Flexibilität nicht leicht fällt (Abbildung 1).

Weitere Anpassungen an der Konfiguration sind in eigenen Dateien im Ordner .ebextensions möglich. Elastic Beanstalk bietet eine fertig eingerichtete, skalierbare, produktive Ablaufumgebung mit Autoskalierung, Monitoring und automatischen Updates der Systemumgebungen. Alternativ lassen sich auch Java-SE-Anwendungen als JAR-Datei oder Java-Anwendungen als Container deployen. Das erfordert jedoch oft das Anpassen einer klassischen Java-EE-Webanwendung oder das Verändern des Deployments. Liegt die Webanwendung noch nicht als Container vor, ist dieser im Build mit geeigneten Plug-ins wie Jib, Buildpacks oder Source-to-Image (S2I) selbst generierbar. Alternativ funktioniert das mit dem Eclipse-JKube-Plug-in äquivalent für Kubernetes-Deployments, und noch einfacher geht es mit dem AWS-App-Runner-Dienst.

Für kleinere Webanwendungen eignet sich auch der Amazon Lightsail Container Service. Bei Kubernetes-Clustern besteht die Wahl zwischen Amazon Elastic Kubernetes Service (EKS), Amazon Elastic Container Service (Amazon ECS) und dem serverlosen AWS Fargate. Ersteres erfordert jedoch größeres Wissen und Aufwände für einen produktiven Betrieb. Außerdem sind weiterhin das Verwalten der Worker-Nodes und die Pflege der Pods beziehungsweise Container notwendig.

Für kleinere Event-orientierte Java-Anwendungen ist der serverlose Lambda-Dienst verwendbar (Abbildung 2). Um Anwendungen als JAR-Datei oder Container-Image zu deployen, ist es jedoch nötig, sie im Sourcecode an Eigenheiten des Lambda-Dienstes anzupassen. Ähnlich wie bei Elastic Beanstalk muss man sich dabei nicht um das Aktualisieren der Java-Laufzeitumgebung, das Verwalten der vorkonfigurierten Ressourcen und deren Skalierbarkeit kümmern, da AWS das übernimmt. Ebenso sind die entsprechenden AWS-Dienste für Logging, Tracing und Monitoring bereits aktiviert, was später bei der Fehlersuche hilfreich sein kann.