Partager via


Choisissez les bons services Azure pour vos applications Java

Cet article vous guide dans l'utilisation des services Azure pour le déploiement d'applications Java, en mettant l'accent sur la prise en charge par Azure de diverses technologies et architectures Java. Il présente des méthodes de déploiement telles que « Lift and Shift », la conteneurisation et Platform-as-a-Service (PaaS), adaptées à différents niveaux de contrôle et de simplicité.

L'article préconise un état d'esprit A+B, vous conseillant de choisir les services en fonction des besoins de l'application plutôt qu'un choix fixe A ou B. Il suggère de prendre en compte le cas d'utilisation, les objectifs commerciaux, la sécurité et le budget pour une approche flexible. L'article souligne le partenariat de Microsoft avec les leaders de l'écosystème Java afin d'améliorer l'expérience des développeurs et recommande les services Azure pour le déploiement des applications Java, qu'il s'agisse de sources, de binaires ou de conteneurs. Cette approche nuancée vous aide à vous concentrer sur l'innovation, soutenue par l'engagement de Microsoft à fournir aux applications Java les services Azure les plus appropriés à votre stratégie de déploiement, en maximisant l'efficacité, l'évolutivité et la rentabilité.

Déployez n'importe quelle application Java en toute confiance et en toute simplicité

L'écosystème Java comprend diverses technologies telles que Java SE, Jakarta EE (successeur de Java EE et J2EE), Spring, de nombreux serveurs d'applications et d'autres frameworks. Quoi que vous fassiez avec Java, qu'il s'agisse de créer une application, d'utiliser un framework ou de faire fonctionner un serveur d'application, Azure prend en charge votre charge de travail avec une abondance de choix. De même, Azure prend en charge n'importe quelle architecture d'application - des applications monolithiques s'exécutant sur des machines virtuelles ou dans des conteneurs aux applications cloud-natives, basées sur des microservices et s'exécutant sur des services entièrement gérés.

Azure propose les trois principales méthodes suivantes pour l'exécution d'applications Java dans le cloud, adaptées à différents niveaux de contrôle et de simplicité :

  • L'approche « Lift and Shift » permet une migration à changement minimal des applications existantes directement vers les machines virtuelles Azure.

  • La conteneurisation offre de la flexibilité, Azure Kubernetes Service (AKS) et Azure Red Hat OpenShift étant les principales plateformes d'orchestration des applications conteneurisées.

  • La plateforme en tant que service (PaaS) représente le summum de la facilité et de l'efficacité, offrant une productivité optimale aux développeurs et une facilité de gestion opérationnelle, souvent associées au coût total de possession le plus économique.

Quel que soit le stade de développement de votre application Java, Azure fournit une solution cloud compatible pour répondre à vos exigences. Pour en savoir plus sur ces offres, consultez la page Déployer des applications Java en toute confiance et en toute simplicité.

Portabilité totale de vos applications Java : déployez-les partout de manière transparente

Quel que soit le service Azure que vous choisissez pour votre application Java, la flexibilité de votre application est garantie. Comme vous disposez du code Java et de ses sorties compilées, vous avez la liberté de déployer votre application où vous le souhaitez, que ce soit sur votre machine de développement locale, sur des serveurs de compilation, dans des environnements sur site ou sur la plateforme cloud de votre choix. La portabilité de votre application est entre vos mains.

Bien sûr, lorsqu'il y a autant de choix, vous êtes confronté à un dilemme.

Dilemme - utiliser le service A ou B pour les applications Java

Si vous parcourez les offres d'Azure, vous serez peut-être confronté à un dilemme : choisir le service Azure le mieux adapté à l'exécution de vos applications Java. Ce choix est crucial, car il influence la planification de vos ressources, votre budget, les délais du projet et, en fin de compte, la mise sur le marché de votre application. La décision a une incidence non seulement sur les coûts de déploiement initiaux, mais aussi sur les dépenses de maintenance courante.

Par le passé, les organisations se sentaient souvent obligées de choisir entre deux plateformes, deux technologies ou deux solutions concurrentes pour leurs applications logicielles. Par exemple, les organisations devaient décider entre WebLogic ou WebSphere pour les applications Java Enterprise, Docker Swarm ou Kubernetes pour la gestion des conteneurs, ou les conteneurs par rapport aux machines virtuelles (VM) pour le déploiement. Ce processus de prise de décision est appelé « état d'esprit A ou B », et il diffère considérablement des tests A/B, qui sont une méthode permettant de comparer deux versions d'une page web ou d'une application l'une par rapport à l'autre afin de déterminer laquelle est la plus performante. Dans ce contexte, l'état d'esprit « A ou B » consiste à choisir une plateforme ou une technologie plutôt qu'une autre pour le déploiement d'une application. Il provient des pratiques locales traditionnelles, où les décisions sont souvent limitées par des facteurs tels que les modèles de livraison de logiciels packages, les investissements initiaux substantiels dans l'infrastructure et les licences logicielles, et les longs délais nécessaires à la construction et au déploiement de toute plateforme d'application.

Transposer cet état d'esprit à Azure peut conduire à consacrer trop de temps à la création d'une plateforme unique tentant d'accueillir toutes les applications, ce qui risque d'entraîner des retards et des inefficacités. Cependant, Azure offre une approche plus avantageuse, encourageant le passage de cet état d'esprit restrictif à un état d'esprit qui englobe le meilleur des deux mondes, ce qui se traduit en fin de compte par un meilleur retour sur investissement (ROI).

Lorsque vous passez à Azure, l'environnement cloud offre un paradigme flexible qui vous permet d'approvisionner et de déprovisionner les ressources en fonction de vos besoins, éliminant ainsi la nécessité de choisir un service plutôt qu'un autre. Cette flexibilité inaugure l'approche A+B, une stratégie qui s'écarte de l'état d'esprit traditionnel A ou B en encourageant un mode de pensée plus large et plus inclusif. Azure facilite ce changement en rendant à la fois facile et rentable la combinaison des avantages de plusieurs services et l'adoption d'un état d'esprit A+B. Cette approche souligne le principe de la sélection des services qui correspondent le mieux aux besoins spécifiques de votre application, préconisant essentiellement le choix du bon outil pour le travail à accomplir.

La transition vers un état d'esprit A+B permet aux organisations d'élargir leurs processus de prise de décision et leurs stratégies techniques, en embrassant les nouvelles possibilités et opportunités qu'offre cet état d'esprit. Cet article décrit les principes de l'état d'esprit A+B, vous permettant de sélectionner judicieusement les services Azure qui répondent le mieux aux exigences de votre application. Qu'il s'agisse d'Azure Container Apps (ACA), d'Azure App Service, d'Azure Kubernetes Service ou de machines virtuelles, l'état d'esprit A+B vous accorde la latitude d'évaluer et de choisir parmi un éventail de services Azure pour héberger vos applications. Cette philosophie est applicable universellement, transcendant les frontières des langages et des frameworks. Bien que nous nous concentrions ici sur les applications Java, l'état d'esprit A+B est tout aussi pertinent et bénéfique pour les applications développées dans n'importe quel langage de programmation.

En adoptant l'état d'esprit A+B, vous n'êtes pas confiné à un service unique et prédéterminé. Au contraire, vous avez la possibilité de combiner les services de la manière la plus adaptée aux exigences uniques de votre application. Cette approche permet non seulement d'améliorer la flexibilité et l'évolutivité, mais aussi d'optimiser les coûts et l'efficacité opérationnelle. Cette approche garantit que votre stratégie technique est aussi dynamique et adaptable que l'environnement cloud dans lequel vous opérez.

Pourquoi il n'est pas nécessaire de penser au service A ou B

Choisir le bon service cloud pour vos applications ne doit pas nécessairement être une décision binaire entre le service A ou le service B, grâce à la flexibilité et à l'étendue des options qu'offre le cloud, en particulier avec Azure. Les sections suivantes expliquent pourquoi il n'est pas nécessaire de s'en tenir au choix traditionnel « l'un ou l'autre » et comment l'adoption d'une approche plus fluide peut être bénéfique pour vos opérations.

Des vieilles habitudes à la nouvelle flexibilité

Traditionnellement, le déploiement de systèmes informatiques impliquait d'importants investissements initiaux en matériel et en logiciels, ainsi que de longs délais d'installation. Cet environnement rendait logique la sélection minutieuse d'une plateforme et l'optimisation de tout ce qui l'entoure afin d'économiser sur les coûts et les ressources. Cependant, l'environnement cloud, y compris Azure, introduit un changement de paradigme avec sa nature à la demande et élastique. Vous ne payez que pour ce que vous utilisez, et l'ajustement de vos ressources pour répondre à vos besoins devient simple, sans le fardeau des dépenses d'investissement initiales.

La transition vers le cloud

Le passage au cloud, et à Azure en particulier, entraîne un changement important dans la manière de gérer les responsabilités liées à l'infrastructure et à la plateforme. Une grande partie des tâches lourdes, auparavant assumées par votre organisation, est désormais confiée à Microsoft, comme le montre le diagramme suivant. Ce changement simplifie les opérations et réduit les efforts nécessaires pour gérer vos applications. Vous n'êtes pas soumis aux contraintes liées à la gestion de plusieurs plateformes, ce qui vous permet de choisir le meilleur outil pour chaque tâche sans vous soucier des coûts supplémentaires et des complexités.

Le diagramme suivant illustre le modèle de responsabilité partagée entre le client et le fournisseur de cloud :

Le diagramme suivant illustre le modèle de responsabilité partagée entre le client et le fournisseur de cloud : Diagramme avec un tableau qui montre le modèle de responsabilité partagée entre le client et le fournisseur de cloud.

Choisir la solution la mieux adaptée à chaque besoin

Dans ce nouveau monde centré sur le cloud, le processus de prise de décision consiste davantage à sélectionner le bon outil pour le bon travail, plutôt que d'essayer de faire entrer tous vos besoins dans un seul service prédéterminé. Qu'il s'agisse de choisir entre Azure Kubernetes Service et Azure Container Apps pour les applications Spring Boot, ou tout autre ensemble de services, l'accent est mis sur ce qui répond le mieux aux exigences de chaque application spécifique.

L'essor des microservices

L'adoption des microservices renforce encore cette approche flexible. De par leur conception, les microservices encouragent l'utilisation de la technologie la mieux adaptée à chaque service, favorisant ainsi une diversité technologique qui s'aligne naturellement sur l'état d'esprit A+B. Cette approche consiste à utiliser les forces des différents services pour construire une architecture d'application plus robuste, plus efficace et plus évolutive.

Avantages de l'approche A+B

L'adoption d'un état d'esprit A+B offre plusieurs avantages clés. Elle permet une plus grande agilité et flexibilité, en vous permettant de choisir les outils et services les plus appropriés pour chaque aspect de vos opérations. Cette approche conduit non seulement à une meilleure efficacité des ressources et des coûts, mais raccourcit également le délai de mise sur le marché de vos produits. En fin de compte, cette approche favorise l'excellence opérationnelle en alignant plus étroitement vos choix technologiques sur les besoins et les objectifs de votre entreprise.

En résumé, le cloud, et Azure en particulier, offre une nouvelle façon d'envisager le déploiement et la gestion de vos applications. En abandonnant le choix restrictif A ou B et en adoptant l'état d'esprit A+B, vous pouvez prendre des décisions qui correspondent mieux aux besoins spécifiques de vos applications, ce qui se traduit par une efficacité, une souplesse et une réduction des coûts accrues.

Conseils pratiques pour passer à l'état d'esprit A+B

La liste suivante énumère quelques principes clés que vous pouvez utiliser comme ligne directrice pour passer à l'état d'esprit A+B et le poursuivre :

  • Passez du cas d'utilisation à la solution, et non l'inverse. Souvent, de nombreuses équipes logicielles décident d'abord de la technologie, puis essaient d'adapter de force les cas d'utilisation et la conception. Dans de nombreux cas, cette approche entraîne des frais généraux importants en termes de coûts, de temps de développement, de ressources et de dépenses opérationnelles. Clarifiez vos cas d'utilisation et vos exigences, tant fonctionnelles que non fonctionnelles, avant de vous lancer dans la solution.

  • Comprenez vos objectifs commerciaux, la nature de l'activité et de votre concurrence, ainsi que la fréquence à laquelle vous devez mettre en production de nouvelles fonctionnalités. Vous devez toujours concevoir votre solution de manière à ce qu'elle réponde aux objectifs de votre entreprise.

  • Comprenez les exigences en matière de sécurité et de conformité. À l'ère du cloud, où l'on accède à tout par internet, la sécurité est cruciale et non négociable. En outre, selon le secteur d'activité auquel vous vous adressez, votre application peut devoir répondre à certaines exigences de conformité. Vous devez concevoir votre solution de manière à ce qu'elle résiste aux attaques de sécurité avancées et qu'elle réponde à vos exigences de conformité.

  • Comprenez votre budget et vos délais. Comprenez clairement votre budget pour le développement initial, les opérations en cours et les versions futures. En outre, comprenez vos délais. Le coût des projets retardés, tant en termes de dépenses supplémentaires que d'impact négatif sur l'entreprise, est souvent sous-estimé. Concevez votre solution de manière à respecter à la fois votre budget et votre calendrier.

  • Pensez à une solution « cloud-native » le cas échéant. L’architecture et les technologies natives Cloud sont une approche de la conception, de la construction et de l’exploitation des charges de travail intégrées dans le cloud et tirent pleinement parti du modèle de cloud computing. Avec le cloud-native, vous pouvez créer et déployer des applications en production à un rythme plus rapide. Le cloud offre également des capacités qui pourraient ne pas être possibles dans les locaux - par exemple, l'élasticité, l'échelle mondiale, l'analyse avancée, l'IA et les capacités de machine learning (ML). Concevez votre solution en vous appuyant autant que possible sur des technologies cloud-natives.

  • Pensez à la culture DevOps. DevOps n'est pas seulement un outil ou un processus, c'est une pratique de développement logiciel qui favorise la collaboration entre le développement et les opérations, ce qui se traduit par une livraison de logiciels plus rapide et plus fiable. Communément appelé culture, DevOps relie les personnes, les processus et la technologie pour fournir une valeur continue.

Choisissez la solution qui répond à vos exigences commerciales et non fonctionnelles, c'est-à-dire celle qui est :

  • La plus rapide à mettre en œuvre.
  • Rentable en termes de coûts de formation, de construction, de déploiement et d'exploitation.
  • Facile à utiliser.
  • Entièrement compatible avec l'automatisation.
  • Favorable à la conception de DevOps.

Ces principes vous aident à vous concentrer sur ce qui doit l'être : construire une solution qui réponde à vos objectifs commerciaux plutôt que d'adapter de force la solution à une plateforme prédéterminée.

Exceptions

Comme toute chose, il existe des exceptions à A+B. La liste suivante n'est pas exhaustive, mais elle vous donne des indications sur certaines exceptions que vous pourriez rencontrer :

  • Stratégie d'entreprise. Par exemple, certaines entreprises adoptent des conteneurs à l'échelle de l'entreprise pour créer et déployer des applications parce qu'elles peuvent avoir plusieurs langages de programmation en jeu et qu'elles veulent créer et déployer toutes les applications d'une manière unifiée.

  • Trop loin dans l'exécution. Vous avez peut-être choisi une solution avant de procéder à l'analyse A+B. Si vous êtes déjà très avancé dans l'exécution de votre solution, poursuivez-la, mais pour la prochaine application, utilisez les principes de l'état d'esprit A+B pour choisir la bonne solution pour votre cas d'utilisation.

  • Migrations de centres de données à grande échelle. Pour accélérer leur parcours vers le cloud, les entreprises utilisent couramment une stratégie appelée « lift and shift » qui consiste à migrer des serveurs (hébergeant leurs applications) en masse vers Azure à l'aide d'outils tels qu'Azure Migrate. Certaines utilisent cette approche pour migrer des centres de données vers Azure et les fermer de manière efficace et rentable. Dans ce scénario, nous recommandons d'utiliser l'état d'esprit A+B pour moderniser les applications après la migration vers Azure.

Considérations relatives aux clés

Nous vous avons fourni le framework de réflexion et les principes que vous pouvez utiliser pour choisir les bonnes destinations dans Azure pour vos applications. Il n'y a pas de taille unique pour tout le monde. Ce n'est pas A ou B, mais A + B.

Le diagramme suivant résume les principales considérations à prendre en compte pour choisir un service Azure pour n'importe quelle application :

Diagramme qui montre un résumé des considérations clés pour choisir un service Azure pour n'importe quelle application.

Comment choisir les bons services Azure pour vos applications Java ?

Pour simplifier le processus de sélection parmi la multitude d'options technologiques pour les applications Java sur Azure, nous avons créé un arbre de décision simple pour aider les développeurs, les clients et les intégrateurs de systèmes à choisir le service Azure optimal.

Au-delà des conseils pratiques concernant les exigences non fonctionnelles, d'un point de vue technologique, la première question à se poser est de savoir si vous avez besoin de contrôler l'infrastructure. Si ce n'est pas le cas, les services gérés sont la meilleure solution. La nature des applications - qu'elles soient basées sur Spring ou App Server - oriente davantage la décision : Les applications Spring s'alignent sur Azure Container Apps, tandis qu'Azure App Service convient aux applications Tomcat ou JBoss EAP.

Pour ceux qui ont besoin de contrôler l'infrastructure, le choix s'articule autour des préférences en matière de technologie multi-cloud : Azure Virtual Machines offre une transition simple, et pour ceux qui sont intégrés à Tanzu, les offres de la place de marché Tanzu on IaaS sont idéales. Les clients qui investissent dans Kubernetes ont le choix entre Azure Kubernetes Service et Azure Red Hat OpenShift. Ce framework décisionnel est conçu pour simplifier les choix en appairant les besoins des clients avec les solutions Azure les mieux adaptées.

Microsoft collabore avec de nombreux partenaires, notamment dans les domaines suivants :

  • Les principaux partenaires de l'écosystème Java, tels qu'Oracle, Broadcom, Red Hat, IBM et OpenAI.
  • Les principales organisations de bases de données et d'outils, telles que MySQL, PostgreSQL, MongoDB Labs, DataStax, Redis Labs, Confluent et Elastic.
  • Les experts en observabilité, tels que New Relic, Dynatrace, AppDynamics, Grafana Labs et Datadog.
  • Des outils de développement, tels que IntelliJ, Maven et Gradle.

Nos investissements combinés sont destinés à faciliter l'expérience des développeurs, à garantir des intégrations transparentes avec des services essentiels tels que les bases de données, les caches, la messagerie et les répertoires, et à fournir des outils complets pour l'observabilité. Grâce à l'automatisation, à l'équilibrage de charge et à l'autoscaling, nous visons à vous décharger du fardeau de la gestion de l'infrastructure. Cette assistance vous permet de vous concentrer sur la création de valeur commerciale à travers votre code, en sachant que les systèmes sous-jacents sont robustes et évolutifs. Pour ces raisons, nous recommandons l'utilisation de services Azure spécifiques pour héberger et exécuter vos types d'applications Java.

Déployez les applications Java sous forme de source ou de binaires

Pour les applications Java sur Azure, qu'elles soient déployées directement à partir du code source ou sous forme de binaires compilés (fichiers JAR, WAR ou EAR), le déploiement est rationalisé grâce aux offres de services complètes d'Azure conçues spécifiquement à cet effet. La portabilité inhérente aux applications Java signifie qu'Azure peut fournir un large éventail de services pour répondre à vos stratégies de déploiement uniques et à vos besoins opérationnels. Cette flexibilité garantit que, quelles que soient les spécificités de votre application Java, il existe un service Azure qui répond parfaitement à vos besoins.

Les trois exemples suivants montrent comment Azure peut répondre à différents scénarios de déploiement d'applications Java :

  • Applications Spring. Pour les développeurs travaillant avec des applications Spring, nous recommandons d'utiliser Azure Container Apps, qui s'intègre à des outils de développement populaires comme IntelliJ, VS Code, Maven et Gradle, aux côtés d'outils d'automatisation comme Azure DevOps, GitHub Actions et Jenkins. Les outils d'observabilité tels que Application Insights, New Relic, Dynatrace, App Dynamics, Grafana, Log Analytics, Elastic et Splunk sont également pris en charge. La sécurité est une priorité absolue, avec des intégrations pour les secrets de gestion Key Vault et les certificats TLS/SSL, l'authentification « sans mot de passe » avec des services de backing via des identités gérées, et le contrôle d'accès basé sur les rôles (RBAC) Azure, garantissant un processus de déploiement sécurisé et rationalisé pour les applications Spring dans le cloud.

  • Applications Java sur JBoss EAP. De même, les applications Java utilisant JBoss EAP bénéficient d'une expérience personnalisée grâce à la collaboration entre l'équipe Microsoft Azure et les équipes Red Hat JBoss EAP. Ce partenariat a permis d'améliorer le support sur Azure App Service, offrant un riche ensemble de fonctionnalités conçues pour les applications JBoss EAP. Ce support vous permet d'utiliser l'expertise combinée de Microsoft et de Red Hat, garantissant ainsi que vos applications Java s'exécutent de manière fluide, sécurisée et efficace sur Azure.

  • Applications Java d'entreprise sur WebLogic. Les applications Java d'entreprise traditionnelles qui s'exécutent sur Oracle WebLogic disposent également d'un chemin dédié vers Oracle sur Azure. La collaboration entre Microsoft Azure et les équipes Oracle WebLogic a ouvert la voie à un déploiement optimisé sur les machines virtuelles Azure. Ce partenariat s'étend à l'intégration des fonctionnalités IaaS fondamentales telles que les machines virtuelles, le stockage, la mise en réseau et les équilibreurs de charge, offrant ainsi une base solide aux applications Java d'entreprise sur Azure. Cet effort coordonné garantit que les applications bénéficient à la fois de la robustesse de WebLogic et de l'évolutivité et de la flexibilité de l'infrastructure Azure.

Ces scénarios soulignent l'engagement d'Azure à offrir un environnement de déploiement flexible, sécurisé et efficace pour les applications Java, en s'adaptant à différents frameworks et architectures. Azure fournit également des services spécialisés pour d'autres applications Java, telles que celles fonctionnant sur Tomcat ou WebSphere, ce qui garantit qu'il existe un service Azure adapté à chaque type d'application Java.

Les développeurs et les opérateurs bénéficient d'une expérience de déploiement dans le cloud fluide et productive en utilisant ces services Azure adaptés, en automatisant et en sécurisant leurs applications Java en toute simplicité. Toutefois, si vous choisissez d'autres options de déploiement, vous devrez peut-être gérer vous-même la création et la maintenance de ces expériences essentielles pour les développeurs et les opérateurs.

Le diagramme suivant présente les services Azure recommandés pour chaque type d'application Java déployée sous forme de source ou de binaires :

Diagramme qui montre les services Azure recommandés pour chaque type d'application Java déployé en tant que source ou binaires.

Pour en savoir plus sur les services référencés dans ce diagramme, utilisez les liens du tableau suivant :

Service Démarrage rapide pour les applications Java - déployées en tant que source ou binaires.
Azure Container Apps Déployer une application Java
Déployer une application Quarkus
App Service Déployer une application Java sur Tomcat
Déployer une application Java sur JBoss EAP
Azure Functions Déployer une application de fonction Java
Machines virtuelles Azure Oracle WebLogic Server sur Azure Virtual Machines
Famille IBM WebSphere sur les machines virtuelles Azure

Déployer des applications Java en tant que conteneurs

Lorsqu'il s'agit de déployer des applications Java, la conteneurisation représente une approche de pointe qui améliore l'automatisation de la création, de la gestion et de la gouvernance des conteneurs dans les entreprises. Le défi consiste à créer des conteneurs de manière sûre et fiable, une étape cruciale pour fournir rapidement des applications logicielles conteneurisées de haute qualité. Ce processus peut partir de zéro ou utiliser des systèmes de conteneurs existants, en intégrant des outils qui compilent et stockent le code et les binaires afin de rationaliser les mises à jour et la gestion des conteneurs. Cette intégration est essentielle pour s'intégrer dans les pipelines d'intégration continue/déploiement continu (CI/CD), offrant une méthode de déploiement flexible pour les applications Java sous forme de conteneur.

Les services Azure se distinguent non seulement en facilitant la livraison d'applications conteneurisées, mais aussi en fournissant des chemins clairs pour le déploiement à partir de sources ou de binaires. Cette double approche minimise l'impact sur les développeurs et allège la charge des opérateurs d'infrastructure ou de plateforme. Compte tenu de la portabilité inhérente à Java, la vaste sélection de services de conteneurs d'Azure vous permet de trouver la solution idéale pour votre stratégie de déploiement et vos besoins.

Les deux exemples suivants montrent comment Azure répond aux scénarios de déploiement d'applications Java conteneurisées :

  • Applications Spring. Azure Container Apps est un excellent choix pour les applications Spring conteneurisées. Il prend en charge plusieurs types de déploiement, notamment les sources, les binaires ou les images de conteneurs. Cette flexibilité vous permet de passer facilement d'une méthode de déploiement à l'autre. Vous pouvez commencer par des conteneurs, puis décider de les déployer sous forme de sources ou de binaires. Cette option est avantageuse car elle vous évite de devoir construire et maintenir en permanence des conteneurs, ce qui peut s'avérer fastidieux, répétitif et chronophage.

  • Applications Java sur Tomcat. Azure App Service est adapté à la conteneurisation d'applications Java conçues pour fonctionner sur Tomcat. Il s'adapte à différents types de déploiement, tels que les binaires ou les images de conteneurs. Comme Azure Container Apps, ce service offre la flexibilité d'alterner entre les stratégies de déploiement. Vous pouvez commencer par le déploiement de conteneurs et conserver la possibilité de passer ultérieurement au déploiement de binaires (WAR et JAR). Cette polyvalence vous permet de choisir la méthode de déploiement la plus efficace pour votre scénario spécifique, ce qui simplifie le processus de développement et de déploiement.

Ces exemples soulignent l'engagement d'Azure à fournir des environnements polyvalents, efficaces et conviviaux pour les développeurs afin de déployer des applications Java, que ce soit par des méthodes traditionnelles ou par la conteneurisation moderne.

Le diagramme suivant présente les services Azure recommandés pour chaque type d'application Java déployée sous forme de conteneurs :

Diagramme qui montre les services Azure recommandés pour chaque type d'application Java déployé en tant que conteneurs.

Pour en savoir plus sur les services référencés dans ce diagramme, utilisez les liens du tableau suivant :

Service Démarrage rapide pour les applications Java conteneurisées
Azure Container Apps Déployer une application Java
Déployer une application Quarkus
App Service Déployer une application Java sur Tomcat
Azure Red Hat OpenShift Déployer une application Java sur JBoss EAP
Azure Kubernetes Service Déployer une application Java sur WebLogic Server
Déployer une application Java sur WebSphere Liberty

Résumé

Dans le cadre du déploiement d'applications Java, Azure adopte une approche A+B nuancée, offrant un éventail de services adaptés aux besoins de chaque application. La collaboration de Microsoft avec les leaders de l'écosystème Java a débouché sur une suite de services Azure, chacun recommandé pour des types d'applications Java spécifiques - déployées sous forme de source, de binaires ou de conteneurs - rationalisant le processus de déploiement et garantissant des performances optimales. Cette volonté de faire correspondre les stratégies de déploiement avec les services Azure les plus appropriés souligne l'engagement de Microsoft à vous offrir la flexibilité nécessaire pour choisir les bons outils pour le travail à accomplir. La portabilité inhérente aux applications Java est un avantage clé, permettant une transition transparente entre les systèmes locaux et les différents fournisseurs de cloud pour améliorer l'efficacité opérationnelle et l'agilité. En préconisant ce processus de sélection plus large et plus inclusif, Microsoft simplifie non seulement le parcours des applications Java dans le cloud, mais maximise également l'évolutivité, la sécurité, l'observabilité et la rentabilité. En fin de compte, les conseils de Microsoft permettent aux développeurs et aux entreprises d'utiliser l'écosystème d'Azure, garantissant que chaque application Java prospère dans l'environnement cloud le mieux adapté à ses besoins.

Étape suivante

Documentation Azure pour les développeurs Java