Comparer les options d’hébergement d’applications Java sur Azure
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 de flamme sont des marques déposées ou des marques de la Fondation Apache Software 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 créées avec des frameworks tels que Spring Boot, Dropwizard, Micronaut, MicroProfile et Vert.x.
Ces applications sont empaquetées dans des archives qui ont l’extension .jar , appelée fichiers JAR.
Applications Spring Cloud
Le style architectural de microservice est une approche du 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 créés avec des infrastructures telles que 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. Certains utilisent directement des API servlet, tandis que d’autres utilisent d’autres frameworks qui encapsulent des API servlet, telles que Apache Struts, Spring MVC et JavaServer Faces.
Les applications web sont empaquetées dans des archives qui ont l’extension .war , connue 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 anciennement appelées applications Java EE ou applications J2EE.
Les applications Jakarta EE peuvent être empaquetées sous forme de fichiers WAR ou d’archives qui ont l’extension .ear , appelées fichiers EAR.
Les applications Jakarta EE doivent être déployées sur des serveurs d’applications conformes à Jakarta EE. Les exemples incluent 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 (Applications de Conteneur Azure) | AKS | Machines virtuelles | |
|---|---|---|---|---|---|---|---|
| Applications Spring Boot / JAR | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Applications Spring Cloud | ✔ | ✔ | ✔ | ✔ | |||
| Applications web | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | |
| Applications Jakarta EE | ✔ | ✔ | ✔ | ||||
| Disponibilité de la région 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
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 de réseau virtuel permet à vos applications d’accéder aux ressources dans ou via 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 telles qu’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 envisager de migrer vers Recherche d’IA 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 Apache Kafka sur Azure peut convenir à 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 (Applications de Conteneur Azure) | AKS | Machines virtuelles | |
|---|---|---|---|---|---|---|---|
| Travaux par lots ou planifiés | ✔ | ✔ | ✔ | ✔ | |||
| Intégration de réseau virtuel | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Sans serveur | ✔ | ✔ | ✔ | ✔ | |||
| Conteneurisation | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ | ✔ |
| Disponibilité de la région 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échargez 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. Certaines plateformes populaires sont 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 populaires 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.
Microprofil
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. Cpuus et Open Liberty sont des implémentations populaires 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.
| Catégorie | Java SE | Microprofil | JarkartaSE | |
|---|---|---|---|---|
| Machine virtuelle | IaaS | ✔ | ✔ | ✔ |
| VMware Tanzu | IaaS | ✔ | ||
| Azure Kubernetes Service | Conteneur | ✔ | ✔ | ✔ |
| Red Hat OpenShift | Conteneur | ✔ | ✔ | ✔ |
| Application conteneur Azure | Paas | ✔ | ✔ | |
| JBoss EAP | 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 du programme principal
- Hang Wang | Gestionnaire de produits
- Xiyi Zhang | Responsable principal du PM
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 du réseau virtuel Azure
- Machines virtuelles dans Azure