Azure offre de nombreuses options pour permettre aux équipes de créer et déployer des applications Java. Cet article décrit les scénarios courants pour Java sur Azure et fournit des suggestions et considérations générales liées à la planification.
Apache®, Apache Kafka, Apache Struts, Apache Tomcat et le logo représentant une flamme sont soit des marques déposées, soit des marques commerciales d’Apache Software Foundation aux États-Unis et/ou dans d’autres pays. L’utilisation de ces marques n’implique aucune approbation de l’Apache Software Foundation.
Plateforme
Avant de sélectionner un scénario cloud pour votre application Java, identifiez sa plateforme. La plupart des applications Java utilisent l’une des plateformes suivantes :
Applications Spring Boot JAR
Les applications Spring Boot JAR sont en règle générale appelées directement à partir de la ligne de commande. Elles gèrent les requêtes web. Au lieu de s’appuyer sur un serveur d’applications pour gérer les requêtes HTTP, ces applications incorporent une communication HTTP et d’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 et Vert.x.
Ces applications sont empaquetées dans des archives portant l’extension .jar, connues sous le nom de fichiers JAR.
Applications 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’appuient sur des fonctionnalités métier.
Des machines de déploiement automatisé déploient indépendamment ces microservices. 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 sous forme de fichiers JAR.
Applications web
Les applications web s’exécutent dans 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 et JavaServer Faces.
Les applications web sont empaquetées dans des archives portant l’extension .war, connues sous le nom de fichiers WAR.
Applications Jakarta EE
Les applications Jakarta Enterprise Edition (Jakarta EE) peuvent contenir une partie, la totalité ou aucun des éléments des applications web. Elles peuvent aussi contenir et consommer de nombreux autres composants comme les définit la spécification Jakarta EE. Les applications Jakarta EE étaient auparavant appelées applications Java EE ou applications J2EE.
Les applications Jakarta EE peuvent être empaquetées sous forme de fichiers WAR ou d’archives portant l’extension .ear, connues sous le nom de fichiers EAR.
Les applications Jakarta EE doivent être déployées sur des serveurs d’applications conformes à Jakarta EE. Il s’agit par exemple de WebLogic, WebSphere, WildFly, GlassFish et Payara.
Les applications qui s’appuient uniquement sur des fonctionnalités fournies par la spécification Jakarta EE 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.
Options de plateforme
Utilisez le tableau suivant pour identifier les plateformes potentielles pour votre type d’application.
| Azure Spring Apps | Java SE sur App Service | Tomcat sur App Service | JBoss EAP sur App Service | Azure Container Apps | AKS | Virtual Machines | |
|---|---|---|---|---|---|---|---|
| Applications Spring Boot/JAR | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Applications Spring Cloud | ✔ | ✔ | ✔ | ✔ | |||
| Applications web | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Applications Jakarta EE | ✔ | ✔ | ✔ | ||||
| Disponibilité dans les régions Azure | Détails | Détails | Détails | Détails | Détails | Détails | Détails |
Azure Kubernetes Service (AKS) et les machines virtuelles 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.
Prise en charge
Outre les choix de plateforme, les applications Java modernes peuvent avoir d’autres besoins en termes de capacité de prise en charge, comme les suivants :
- Programmes de traitement par lot ou tâches planifiées
- Intégration du réseau virtuel
- Sans serveur
- Mise en conteneur
Programmes de traitement par lot ou tâches planifiées
Au lieu d’attendre des requêtes ou une entrée utilisateur, certaines applications s’exécutent brièvement, exécutent une charge de travail particulière, puis se ferment. Parfois, ces tâches ont besoin de s’exécuter une seule fois ou à intervalles réguliers et planifiés. Localement, de telles tâches sont souvent appelées à partir de la table Cron d’un serveur.
Ces applications sont empaquetées sous forme de fichiers JAR.
Notes
Si votre application utilise un planificateur, comme Spring Batch ou Quartz, pour exécuter des tâches planifiées, nous vous recommandons vivement de le faire en dehors de l’application. Si votre application se met à l’échelle sur plusieurs instances dans le cloud, alors la même tâche peut s’exécuter plusieurs fois. Si votre mécanisme de planification utilise le fuseau horaire local de l’hôte, un comportement non souhaité peut se produire quand vous mettez à l’échelle une application d’une région à l’autre.
Intégration du réseau virtuel
Quand vous déployez une application Java dans votre réseau virtuel, elle comporte des dépendances sortantes vis-à-vis de services extérieurs au réseau virtuel. Pour la gestion et les opérations, votre projet doit avoir accès à certains ports et noms de domaine complets. Les réseaux virtuels Azure vous permettent de placer un grand nombre de vos ressources Azure dans un réseau routable non-Internet. La fonctionnalité d’intégration au réseau virtuel permet à vos applications d’accéder à des ressources à l’intérieur ou par le biais d’un réseau virtuel. Elle n’autorise pas l’accès privé à vos applications.
Modèle de développement serverless
Le modèle de développement serverless est un modèle natif Cloud qui permet aux développeurs de générer et d’exécuter des applications sans avoir à gérer des serveurs. Avec des applications serverless, le fournisseur de services cloud provisionne, met à l’échelle et gère automatiquement l’infrastructure nécessaire pour exécuter le code. Il existe quand même des serveurs dans le modèle serverless. Ils sont extraits du développement d’applications.
Mise en conteneur
La conteneurisation correspond à l’empaquetage du code logiciel avec tous ses composants nécessaires, comme les bibliothèques, les frameworks et d’autres dépendances. L’application est isolée dans son propre conteneur.
CI/CD
L’intégration continue et la livraison continue (CI/CD) constituent une méthode permettant de livrer fréquemment des applications aux clients en introduisant une automatisation dans les phases de développement d’applications. Les principaux concepts de CI/CD sont l’intégration continue, la livraison continue et le déploiement continu. Tous les choix Azure prennent en charge la plupart des outils CI/CD. Par exemple, vous pouvez utiliser des solutions comme Azure Pipelines ou Jenkins.
Moteur de recherche open source
Les recherches font partie intégrante de toute application. Si la vitesse, les performances et la haute disponibilité sont essentielles, les recherches effectuées sur des téraoctets et pétaoctets de données peuvent s’avérer délicates. Quand vous hébergez des applications Java sur Azure, prévoyez d’héberger vos instances Solr et Elasticsearch associées. Vous pouvez également effectuer une migration vers Recherche cognitive Azure.
Outils Big Data
Les outils Big Data permettent d’automatiser le flux de données entre les systèmes logiciels. Ils prennent en charge des graphes de routage des données évolutifs, robustes et simplifiés, ainsi que la logique de médiation système. Ils sont utilisés pour créer des pipelines de flux de données actives et diffuser des applications en streaming. Découvrez comment Nifi et Apache Kafka sur Azure peuvent répondre à vos besoins.
Options de capacité de prise en charge
Utilisez le tableau suivant pour identifier les options potentielles pour votre type d’application. AKS et les machines virtuelles prennent en charge tous les types d’applications, mais exigent que votre équipe endosse plus de responsabilités.
| Azure Spring Apps | Java SE sur App Service | Tomcat sur App Service | JBoss EAP sur App Service | Azure Container Apps | AKS | Virtual Machines | |
|---|---|---|---|---|---|---|---|
| Programmes de traitement par lot ou tâches planifiées | ✔ | ✔ | ✔ | ✔ | |||
| Intégration du réseau virtuel | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Sans serveur | ✔ | ✔ | ✔ | ✔ | |||
| Mise en conteneur | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Disponibilité dans les régions Azure | Détails | Détails | Détails | Détails | Détails | Détails | Détails |
Reportez-vous également à cet arbre de décision.
Télécharger un fichier Visio de ce diagramme.
Générer ou migrer des applications Java
Pour générer ou migrer les applications Java, identifiez la plateforme Java de vos applications. Les plateformes connues sont notamment Java SE, Jakarta EE et MicroProfile.
Java SE
La plateforme Java SE (Standard Edition) est une plateforme informatique pour le développement et le déploiement de code portable pour des environnements bureau et serveur. Les projets connus basés sur Java SE incluent Spring Boot, Spring Cloud, Spring Framework et Apache Tomcat.
Jakarta EE
Jakarta EE incarne l’avenir open source de la version native Cloud pour entreprise de Java. Il s’agit d’un ensemble de spécifications qui étendent Java SE avec des fonctionnalités d’entreprise comme l’informatique distribuée et les services web. Les applications Jakarta EE exécutent des runtimes de référence. Ces runtimes peuvent être des microservices ou des serveurs d’applications. Ils gèrent les transactions, la sécurité, la scalabilité, la concurrence et la gestion des composants déployés par l’application.
MicroProfile
Le projet MicroProfile fournit une collection de spécifications conçues pour aider les développeurs à générer des microservices natifs Cloud Enterprise Java. Quarkus et Open Liberty sont des implémentations reconnues de MicroProfile.
Résumé de la génération ou migration
Le tableau suivant fournit des informations de génération ou de migration par type d’application et service Azure.
| Type | Java SE | MicroProfile | JarkartaSE | |
|---|---|---|---|---|
| Machine virtuelle | IaaS | ✔ | ✔ | ✔ |
| VMware Tanzu | IaaS | ✔ | ||
| Azure Kubernetes Service | Conteneur | ✔ | ✔ | ✔ |
| Red Hat OpenShift | Conteneur | ✔ | ✔ | ✔ |
| Azure Container App | PaaS | ✔ | ✔ | |
| EAP JBoss | App Service PaaS | ✔ | ✔ | |
| Apache Tomcat | App Service PaaS | ✔ | ||
| Java SE | App Service PaaS | ✔ | ✔ | |
| Azure Spring Apps | PaaS | ✔ |
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteurs principaux :
- Asir Vedamuthu Selvasingh | Responsable de programme principal
- Hang Wang | Chef de produit
- Xinyi Zhang | Responsable PM principal
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Vue d’ensemble d’Azure Container Apps
- Azure Kubernetes Service
- Documentation Azure Spring Apps
- Intégration de réseau virtuel Azure
- Machines virtuelles dans Azure