Migrieren von Java-Anwendungen zu Azure

Dieser Artikel bietet einen Überblick über die empfohlenen Strategien für die Migration von Java-Anwendungen zu Azure.

Dieser Migrationsleitfaden wurde für gängige Szenarien mit Java in Azure konzipiert und enthält allgemeine Planungsvorschläge und -aspekte. Wenn Sie ein bestimmtes Szenario für die Migration von Java Apps mit dem Microsoft Java auf Azure Team besprechen möchten, füllen Sie den folgenden Fragebogen aus, und ein Mitarbeiter wird sich mit Ihnen in Verbindung setzen.

Identifizieren des Anwendungstyps

Bevor Sie für Ihre Java-Anwendung ein Cloudziel auswählen, müssen Sie den Anwendungstyp ermitteln. Bei den meisten Java-Anwendungen handelt es sich um einen der folgenden Typen:

• Spring-Anwendungen:
  • Spring Boot-/JAR-Anwendungen
  • Spring-Anwendungen, die Spring Cloud-Middleware-Module verwenden
• Java EE-Anwendungen
• Webanwendungen
• Batchaufträge/Geplante Aufträge

Diese Anwendungstypen werden in den folgenden Abschnitten beschrieben.

Spring Boot-/JAR-Anwendungen

Viele neuere Anwendungen werden direkt über die Befehlszeile aufgerufen. Mit diesen Anwendungen werden auch weiterhin Webanforderungen verarbeitet. Aber anstatt den Anwendungsserver für die Verarbeitung von HTTP-Anforderungen zu nutzen, werden die HTTP-Kommunikation und alle anderen Abhängigkeiten direkt in das Anwendungspaket eingebunden. Anwendungen dieser Art werden häufig mit Frameworks erstellt, z. B. Spring Boot, Dropwizard, Micronaut, MicroProfile, Vert.x und anderen.

Diese Anwendungen werden in Archiven mit der Erweiterung .jar (JAR-Dateien) angeordnet.

Spring-Anwendungen, die Spring Cloud-Middleware-Module verwenden

Der Microservice-Architekturstil ist ein Ansatz für die Entwicklung einer einzelnen Anwendung als Suite mit kleinen Diensten. Diese Dienste werden jeweils als eigener Prozess ausgeführt und kommunizieren über einfache Mechanismen – häufig mit einer HTTP-Ressourcen-API. Diese Dienste basieren auf den Geschäftsfunktionen und können über vollständig automatisierte Prozesse unabhängig voneinander bereitgestellt werden. Es gibt nur ein Minimum an zentraler Verwaltung dieser Dienste, die in verschiedenen Programmiersprachen geschrieben sein können und unterschiedliche Technologien zur Datenspeicherung verwenden. Dienste dieser Art werden häufig mit Frameworks, z. B. Spring Cloud, erstellt.

Die Dienste werden in mehreren Anwendungen mit der Erweiterung .jar (JAR-Dateien) angeordnet.

Java EE-Anwendungen

Java EE-Anwendungen (auch als J2EE-Anwendungen oder neuerdings als Jakarta EE-Anwendungen bezeichnet) können einige, alle oder keine der Elemente von Webanwendungen enthalten. Diese Anwendungen können auch viele weitere Komponenten enthalten und verbrauchen, wie in der Jakarta EE-Spezifikation definiert.

Java EE-Anwendungen können in Archiven mit der Erweiterung .ear (EAR-Dateien) oder .war (WAR-Dateien) gepackt werden.

Java EE-Anwendungen müssen auf Java EE-kompatiblen Anwendungsservern bereitgestellt werden (wie z. B. Oracle WebLogic Server, IBM WebSphere, JBoss EAP, GlassFish, Payara und andere).

Anwendungen, die nur auf den Features der Java EE-Spezifikation basieren (also vom App-Server unabhängige Anwendungen), können von einem konformen Anwendungsserver zu einem anderen migriert werden. Falls Ihre Anwendung von einem bestimmten Anwendungsserver abhängig ist (App-Server-Abhängigkeit), müssen Sie ggf. ein Azure-Dienstziel auswählen, auf dem Sie den Anwendungsserver hosten können.

Webanwendungen

Webanwendungen werden in einem Servlet-Container ausgeführt. Einige dieser Anwendungen verwenden Servlet-APIs direkt, während viele andere Frameworks verwenden, die Servlet-APIs kapseln, wie z. B. Apache Struts, Spring MVC, JavaServer Faces (JSF) und andere.

Webanwendungen werden in Archiven mit der Erweiterung .war (WAR-Dateien) angeordnet.

Batchaufträge/Geplante Aufträge

Für einige Anwendungen ist vorgesehen, dass sie nur kurz ausgeführt werden, eine bestimmte Workload ausführen und dann beendet werden, anstatt auf Anforderungen oder Benutzereingaben zu warten. Diese Aufträge müssen teils nur einmal, teils aber auch in regelmäßigen geplanten Intervallen ausgeführt werden. In lokalen Umgebungen werden diese Aufträge häufig über das crontab-Element eines Servers aufgerufen.

Diese Anwendungen werden in Archiven mit der Erweiterung .jar (JAR-Dateien) angeordnet.

Auswählen des Azure-Dienstziels

In den folgenden Abschnitten wird veranschaulicht, welche Dienstziele Ihre Anwendungsanforderungen erfüllen und welche Zuständigkeiten damit verbunden sind.

Übersicht über die Hostingoptionen

Anhand der folgenden Übersicht können Sie potenzielle Ziele für Ihren Anwendungstyp ermitteln. Wie Sie sehen, unterstützen Azure Kubernetes Service (AKS) und Azure Virtual Machines alle Anwendungstypen, aber sie verlangen von Ihrem Team mehr Verantwortung, wie im nächsten Abschnitt gezeigt wird.

Raster zu laufenden Zuständigkeiten

Ermitteln Sie anhand des folgenden Rasters, welche Zuständigkeiten sich nach der Migration in Bezug auf die einzelnen Ziele für Ihr Team ergeben.

Die mit gekennzeichneten Aufgaben werden ganz oder größtenteils von Azure verwaltet. Ihr Team ist fortlaufend für die mit  gekennzeichneten Aufgaben verantwortlich. Wir empfehlen Ihnen, zur Erfüllung dieser Zuständigkeiten einen stabilen, stark automatisierten Prozess zu implementieren.

Ziel → Aufgabe ↓	App Dienst	Azure Container Apps	AKS	Virtual Machines
Aktualisieren von Bibliotheken (einschließlich Behebung von Sicherheitsrisiken)	👉	👉	👉	👉
Aktualisieren des Anwendungsservers (einschließlich Behebung von Sicherheitsrisiken)		👉	👉	👉
Aktualisieren der Java Runtime (einschließlich Behebung von Sicherheitsrisiken)		👉	👉	👉
Auslösen von Kubernetes-Updates (durchgeführt von Azure per manuellem Trigger)	N/V		👉	N/V
Notfallwiederherstellung		👉	👉
Abstimmen von nicht abwärtskompatiblen Änderungen der Kubernetes-API	–	👉	👉	–
Aktualisieren des Container-Basisimages (einschließlich Behebung von Sicherheitsrisiken)	–	👉	👉	–
Aktualisieren des Betriebssystems (einschließlich Behebung von Sicherheitsrisiken)			1	👉
Erkennen und Neustarten von Instanzen mit Fehlern				👉
Implementieren des Ausgleichs und parallelen Neustarts für Updates				👉
Infrastrukturverwaltung		👉	👉	👉
Überwachung und Warnungsverwaltung	👉	👉	👉	👉

¹ Einige Sicherheitsupdates erfordern möglicherweise einen Neustart des Knotens, der nicht automatisch durchgeführt wird. Weitere Informationen finden Sie unter Übernahme von Sicherheits- und Kernel-Updates auf Linux Knoten in Azure Kubernetes Services (AKS).

Wenn Sie den Servlet-Container (z. B. Spring Boot) als Teil Ihrer Anwendung bereitstellen, sollten Sie diesen als Bibliothek ansehen. Er liegt somit in Ihrem Zuständigkeitsbereich.

Sicherstellen der lokalen Konnektivität

Wenn Ihre Anwendung auf Ihre lokalen Dienste zugreifen muss, müssen Sie einen der Konnektivitätsdienste von Azure bereitstellen. Weitere Informationen finden Sie unter Herstellen einer Verbindung zwischen einem lokalen Netzwerk und Azure. Alternativ müssen Sie Ihre Anwendung so umgestalten, dass öffentlich zugängliche APIs genutzt werden, die von Ihren lokalen Ressourcen verfügbar gemacht werden.

Sie sollten diesen Vorgang durchführen, bevor Sie mit der Migration beginnen.

Bestand: Aktuelle Kapazität und Ressourcennutzung

Dokumentieren Sie die Hardware der aktuellen Produktionsserver sowie die durchschnittliche und maximale Anzahl von Anforderungen und die Ressourcennutzung. Sie benötigen diese Informationen, um Ressourcen auf dem Dienstziel bereitzustellen.

Migrationsanleitung

Verwenden Sie die folgenden Raster, um Informationen zur Migration nach Anwendungstyp und gewünschtem Azure-Dienstziel zu erhalten.

Java-Anwendungen

Ermitteln Sie in den folgenden Zeilen Ihren Java-Anwendungstyp und die Spalten, um das Azure-Dienstziel zu finden, auf dem Ihre Anwendung gehostet wird.

Wenn Sie eine JBoss EAP-App zu Tomcat unter App Service migrieren möchten, sollten Sie zuerst die Java EE-App in Java-Web-Apps (Servlets) konvertieren, die unter Tomcat ausgeführt werden, und dann den unten angegebenen Leitfaden befolgen.

Java EE-Anwendungen

Ermitteln Sie anhand der unten angegebenen Zeilen den Typ Ihrer Java EE-Anwendung, die auf einem bestimmten App-Server ausgeführt wird. In den Spalten finden Sie das Azure-Dienstziel, auf dem Ihre Anwendung gehostet wird.

Siehe auch

• Gründe für den Wechsel zu Java 11 und darüber hinaus
• Umstellung von Java 8 auf Java 11
• Umstellung von Java 7 auf Java 8