Migrer des applications Java vers Azure
Cet article fournit une vue d’ensemble des stratégies recommandées pour la migration d’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.
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 :
- Applications Spring :
- Applications Java EE
- Applications web
- Tâches planifiées/par lot
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 portant l’extension .jar (fichiers JAR).
Applications Spring qui utilisent des modules d’intergiciel 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. Il existe un minimum de gestion centralisée de ces services, qui peuvent ê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 portant 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 certaines, toutes ou aucune 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 portant l’extension .ear (fichiers EAR) ou en tant qu’archives portant 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 dans un conteneur Servlet. Certaines de ces applications utilisent directement des API servlet, tandis que beaucoup utilisent d’autres frameworks qui encapsulent des API servlet, telles qu’Apache Struts, Spring MVC, JavaServer Faces (JSF) et d’autres.
Les applications web sont empaquetées dans des archives portant 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 portant 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 vous pouvez le voir, Azure Kubernetes Service (AKS) et Azure Machines Virtuelles prennent en charge tous les types d’applications, mais ils nécessitent que votre équipe prenne davantage de responsabilités, comme indiqué dans la section suivante.
| → de destination Type d’application ↑ |
Application Service Java SE |
Application Service Tomcat |
Application Service JBoss EAP |
Azure Spring Applications |
Azure Container Apps | AKS | Machines Virtuelles |
|---|---|---|---|---|---|---|---|
| Applications Spring Boot/JAR | ✔ | ||||||
| Applications Spring Cloud | ✔ | ✔ | ✔ | ✔ | |||
| Applications web | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Applications Java EE | ✔ | ✔ | ✔ | ||||
| Serveurs d’applications commerciales (par exemple, Oracle WebLogic Server ou IBM WebSphere) |
✔ | ✔ | ✔ | ||||
| Persistance à long terme sur le système de fichiers local | ✔ | ✔ | ✔ | ✔ | ✔ | ||
| 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 | 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 
sont gérées entièrement ou principalement par Azure. Votre équipe est responsable en permanence des tâches indiquées avec 👉. 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 |
Azure Spring Applications |
Azure 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) |
|
|
👉 | 👉 | 👉 |
| Mise à jour du runtime Java (correction des vulnérabilités comprise) |
|
|
👉 | 👉 | 👉 |
| Déclenchement des mises à jour Kubernetes (effectué par Azure avec un déclencheur manuel) |
S/O | |
|
👉 | S/O |
| Récupération d’urgence | |
|
👉 | 👉 | |
| 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) |
|
|
|
1 |
👉 |
| Détection et redémarrage des instances ayant échoué | |
|
|
|
👉 |
| Implémentation du drainage et du redémarrage progressif pour les mises à jour | |
|
|
|
👉 |
| Gestion des infrastructures | |
|
👉 | 👉 | 👉 |
| 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 Choisir une solution pour 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.
Si vous souhaitez migrer une application web sur Tomcat vers Azure Spring Apps, commencez par convertir l’application en applications Spring Cloud, puis suivez les instructions indiquées ci-dessous.
| → de destination Type d’application ↑ |
Application Service Java SE |
Application Service Tomcat |
Application Service JBoss EAP |
Azure Conteneur Applications |
Azure Spring Applications |
AKS | Machines Virtuelles |
|---|---|---|---|---|---|---|---|
| Spring Boot/ applications JAR |
N/A | N/A | N/A | N/A | Conseils | N/A | N/A |
| Spring Cloud/ applications |
N/A | N/A | N/A | N/A | Conseils | Conseils planifié |
Conseils planifié |
| Applications Web sur Tomcat |
S/O | Conseils | S/O | Conseils | S/O | Conseils | 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 Tomcat |
Application Service JBoss EAP |
Azure Conteneur Applications |
Azure Spring Applications |
AKS | Machines Virtuelles |
|---|---|---|---|---|---|---|---|
| WildFly/ JBoss AS |
N/A | N/A | Conseils | N/A | N/A | Conseils | Conseils planifié |
| Oracle WebLogic Server | N/A | N/A | Conseils | N/A | N/A | Conseils | Conseils |
| IBM WebSphere | N/A | N/A | Conseils | N/A | N/A | Conseils | Conseils planifié |
| Red Hat JBoss EAP | N/A | N/A | Conseils | N/A | N/A | Conseils | Conseils |
Voir aussi
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour