Partager via

Migrer des applications Java vers Azure

Cet article fournit une vue d’ensemble des stratégies recommandées pour migrer des applications Java vers Azure.

Ce guide de migration est conçu pour couvrir les scénarios Java courants sur Azure et pour fournir des suggestions et des considérations de planification générales. Si vous souhaitez discuter d’un scénario de migration d’application Java spécifique avec l’équipe Microsoft Java sur Azure, remplissez le questionnaire suivant et un représentant vous contactera.

Questionnaire de migration Java

Identification du type d’application

Avant de sélectionner une destination cloud pour votre application Java, vous avez besoin d’identifier son type. La plupart des applications Java sont de l’un des types suivants :

Ces types sont décrits dans les sections suivantes.

Applications Spring Boot/JAR

De nombreuses applications récentes sont appelées directement à partir de la ligne de commande. Ces applications gèrent toujours les requêtes web, mais au lieu de s’appuyer sur un serveur d’application pour assurer la gestion des requêtes HTTP, elles incorporent la communication HTTP et toutes les autres dépendances directement dans le package d’application. Ces applications sont souvent générées avec des frameworks comme Spring Boot, Dropwizard, Micronaut, MicroProfile, Vert.x, etc.

Ces applications sont empaquetées dans des archives avec l’extension .jar (fichiers JAR).

Applications Spring qui utilisent des modules de middleware Spring Cloud

Le style architectural de microservice est une approche de développement d’une application unique en tant que suite de petits services, chacun s’exécutant dans son propre processus et communiquant avec des mécanismes légers, souvent une API de ressource HTTP. Ces services s’articulent autour de fonctionnalités métier et peuvent être déployés indépendamment par des machines de déploiement entièrement automatisées. La gestion centralisée de ces services est réduite au strict minimum, ces derniers pouvant être écrits dans différents langages de programmation et utiliser différentes technologies de stockage de données. Ces services sont souvent générés avec des frameworks comme Spring Cloud.

Ces services sont empaquetés dans plusieurs applications avec l’extension .jar (fichiers JAR).

Applications Java EE

Les applications Java EE (également appelées applications J2EE ou, plus récemment, applications Jakarta EE) peuvent contenir une partie, la totalité ou aucun des éléments des applications web. Ces applications peuvent également contenir et consommer de nombreux autres composants tels que définis par la spécification Jakarta EE.

Les applications Java EE peuvent être empaquetées en tant qu’archives avec l’extension .ear (fichiers EAR) ou en tant qu’archives avec l’extension .war (fichiers WAR).

Les applications Java EE doivent être déployées sur des serveurs d’applications compatibles Java EE (comme Oracle WebLogic Server,IBM WebSphere, JBoss EAP, GlassFish, Payara, etc.).

Les applications qui s’appuient uniquement sur des fonctionnalités fournies par la spécification Java EE (autrement dit, les applications indépendantes du serveur d’applications) peuvent être migrées d’un serveur d’applications conforme vers un autre. Si votre application dépend d’un serveur d’applications spécifique, vous avez peut-être besoin de sélectionner une destination de service Azure qui vous permet d’héberger ce serveur d’applications.

Applications web

Les applications web s’exécutent à l’intérieur d’un conteneur Servlet . Certaines utilisent des API de servlet directement, tandis que d’autres utilisent d’autres frameworks qui encapsulent des API de servlet, comme Apache Struts, Spring MVC, JavaServer Faces (JSF), etc.

Les applications web sont empaquetées dans des archives avec l’extension .war (fichiers WAR).

Tâches planifiées/par lot

Certaines applications ont vocation à s’exécuter brièvement, à exécuter une charge de travail particulière, puis à se fermer au lieu d’attendre des requêtes ou une entrée utilisateur. Ces tâches doivent parfois s’exécuter une seule fois ou à intervalles réguliers et planifiés. Localement, de telles tâches sont souvent appelées à partir du crontab d’un serveur.

Ces applications sont empaquetées dans des archives avec l’extension .jar (fichiers JAR).

Remarque

Si votre application utilise un planificateur (comme Spring Batch ou Quartz) pour exécuter des tâches planifiées, nous vous recommandons vivement de factoriser ces tâches pour qu’elles s’exécutent en dehors de l’application. Si votre application se met à l’échelle sur plusieurs instances dans le cloud, alors la même tâche s’exécute plusieurs fois. De plus, si votre mécanisme de planification utilise le fuseau horaire local de l’hôte, vous pouvez être confronté à un comportement indésirable lors de la mise à l’échelle de votre application dans plusieurs régions.

Sélection de la destination du service Azure cible

Les sections suivantes indiquent les destinations de service qui répondent aux besoins de votre application, ainsi que les responsabilités qu’elles impliquent.

Grille d’options d’hébergement

Utilisez la grille suivante pour identifier les destinations potentielles pour votre type d’application. Comme on peut le voir, Azure Kubernetes Service (AKS) et les machines virtuelles Azure prennent en charge tous les types d’applications, mais exigent que votre équipe endosse plus de responsabilités, comme décrit dans la section suivante.

→ de destination

Type d’application ↓		 Application
Service
Java SE		 Application
Service
Matou		 Application
Service
EAP JBoss		 Azure Container Apps (Applications de Conteneur Azure) AKS Machines
Virtuelles
Applications Spring Boot/JAR ✔ ✔ ✔ ✔
Applications Spring Cloud ✔ ✔ ✔ ✔ ✔
Applications web (WAR) ✔ ✔ ✔ ✔ ✔
Applications Java EE (WAR | EAR) ✔ ✔ ✔ ✔
Serveurs d’applications commerciales
(par exemple, Oracle WebLogic Server ou IBM WebSphere)		 ✔ ✔ ✔
Clustering au niveau du serveur d’applications ✔ ✔ ✔
Tâches planifiées/par lot ✔ ✔ ✔
Intégration au réseau virtuel/connectivité hybride ✔ ✔ ✔ ✔ ✔ ✔
Disponibilité dans les régions Azure Détails Détails Détails Détails Détails Détails

Grille des responsabilités

Utilisez la grille suivante pour comprendre la responsabilité que chaque destination impose à votre équipe en charge du suivi de la migration.

Les tâches indiquées avec Azure sont gérées entièrement ou principalement par Azure. Votre équipe est responsable en continu des tâches indiquées par 👉. Nous vous recommandons d’implémenter un processus robuste et hautement automatisé pour assumer toutes ces responsabilités.

Remarque

Cette liste des responsabilités n’est pas exhaustive.

→ de destination

Tâche ↓		 Application
Service		 Azur
Conteneur
Applications		 AKS Machines
Virtuelles
Mise à jour des bibliothèques
(correction des vulnérabilités comprise)		 👉 👉 👉 👉
Mise à jour du serveur d’applications
(correction des vulnérabilités comprise)		 Azur 👉 👉 👉
Mise à jour du runtime Java
(correction des vulnérabilités comprise)		 Azur 👉 👉 👉
Déclenchement des mises à jour Kubernetes
(effectué par Azure avec un déclencheur manuel)		 S/O Azur 👉 S/O
Récupération d’urgence Azur 👉 👉 Azur
Rapprochement des changements d’API Kubernetes hors compatibilité descendante S/O 👉 👉 S/O
Mise à jour de l’image conteneur de base
(correction des vulnérabilités comprise)		 S/O 👉 👉 S/O
Mise à jour du système d’exploitation
(correction des vulnérabilités comprise)		 Azur Azur Azure 1 👉
Détection et redémarrage des instances ayant échoué Azur Azur Azur 👉
Implémentation du drainage et du redémarrage progressif pour les mises à jour Azur Azur Azur 👉
Gestion des infrastructures Azur 👉 👉 👉
Supervision et gestion des alertes 👉 👉 👉 👉

1 Certaines mises à jour de sécurité peuvent nécessiter des redémarrages de nœud, qui ne sont pas effectués automatiquement. Pour plus d’informations, consultez Appliquer des mises à jour de sécurité et de noyau aux nœuds Linux dans Azure Kubernetes Service (AKS).

Si vous déployez le conteneur de servlet (par exemple, Spring Boot) dans le cadre de votre application, vous devez le considérer comme une bibliothèque et, en tant que telle, il est toujours de votre responsabilité.

Garantie de la connectivité locale

Si votre application doit accéder à vos services locaux, vous devez provisionner l’un des services de connectivité d’Azure. Pour plus d’informations, consultez Connecter un réseau local à Azure. Vous avez également besoin de refactoriser votre application pour qu’elle utilise les API publiques disponibles que vos ressources locales exposent.

Vous devez réaliser ce travail avant de commencer toute migration.

Inventorier la capacité et l’utilisation des ressources actuelles

Documentez le matériel des serveurs de production actuels, ainsi que le nombre moyen et maximal de requêtes et l’utilisation des ressources. Vous avez besoin de ces informations pour provisionner des ressources dans la destination du service.

Recommandations en matière de migration

Utilisez les grilles suivantes pour rechercher des conseils de migration par type d’application et par destination de service Azure ciblée.

Applications Java

Utilisez les lignes ci-dessous pour rechercher votre type d’application Java et les colonnes pour rechercher la destination de service Azure qui va héberger votre application.

Si vous souhaitez effectuer la migration d’une application JBoss EAP vers Tomcat sur App Service, commencez par convertir l’application Java EE en une application web Java (servlets) exécutée sur Tomcat, puis suivez les instructions indiquées ci-dessous.

→ de destination

Type d’application ↓		 Application
Service
Java SE		 Application
Service
Matou		 Application
Service
EAP JBoss		 Azur
Conteneur
Applications		 AKS Machines
Virtuelles
Spring Boot/
applications JAR		 aide S/O S/O S/O S/O S/O
Spring Cloud/
Applications		 S/O S/O S/O S/O Conseils
planifié		 Conseils
planifié
Applications web
sur Tomcat		 S/O aide S/O aide aide Conseils
planifié

Applications Java EE

Utilisez les lignes ci-dessous pour rechercher le type de votre application Java EE s’exécutant sur un serveur d’applications spécifique. Utilisez les colonnes pour rechercher la destination de service Azure qui va héberger votre application.

→ de destination

Serveur d’applications ↑		 Application
Service
Java SE		 Application
Service
Matou		 Application
Service
EAP JBoss		 Azur
Conteneur
Applications		 AKS Machines
Virtuelles
JBoss AS S/O S/O aide S/O S/O Conseils
planifié
Oracle WebLogic Server S/O S/O aide S/O aide aide
IBM WebSphere S/O S/O aide S/O aide Conseils
planifié
Red Hat JBoss EAP S/O S/O aide S/O S/O aide

Voir aussi

  • Last updated on