Choisir les services Azure appropriés pour vos applications Java
Cet article vous guide sur l’utilisation des services Azure pour le déploiement d’applications Java, en mettant l’accent sur la prise en charge d’Azure pour diverses technologies et architectures Java. Il décrit les méthodes de déploiement telles que « Lift and Shift », conteneurisation et PaaS (Platform-as-a-Service), adaptées aux différents niveaux de contrôle et de simplicité.
L’article préconise un état d’esprit A+B, vous conseillant de choisir des services en fonction des besoins de l’application sur un choix fixe A ou B. Il suggère d’envisager le cas d’usage, les objectifs métier, la sécurité et le budget pour une approche flexible. L’article met en évidence le partenariat de Microsoft avec les leaders de l’écosystème Java pour améliorer les expériences des développeurs et recommander des services Azure pour le déploiement d’applications Java , que ce soit en tant que sources, binaires ou conteneurs. Cette approche nuance vous aide à vous concentrer sur l’innovation, prise en charge par l’engagement de Microsoft à fournir aux applications Java les services Azure les plus appropriés pour votre stratégie de déploiement, en optimisant l’efficacité, l’extensibilité et l’efficacité des coûts.
Déployer n’importe quelle application Java avec confiance et facilité
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 infrastructures. Ce que vous faites avec Java, comme la création d’une application, l’utilisation d’une infrastructure et l’exécution d’un serveur d’applications, support Azure votre charge de travail avec une abondance de choix. De même, support Azure toute architecture d’application , des applications monolithiques s’exécutant sur des machines virtuelles ou dans des conteneurs à des applications basées sur le cloud natives et basées sur des microservices s’exécutant sur des services entièrement managés.
Azure propose les trois méthodes principales suivantes pour exécuter des applications Java dans le cloud, adaptées à différents niveaux de contrôle et de simplicité :
L’approche « Lift and Shift » permet une migration minimale des applications existantes directement vers Azure Machines Virtuelles.
La conteneurisation offre une flexibilité, avec Azure Kubernetes Service (AKS) et Azure Red Hat OpenShift étant les principales plateformes pour orchestrer des applications conteneurisées.
PaaS (Platform-as-a-Service) représente le sommet de la facilité et de l’efficacité, offrant une productivité optimale des développeurs et une facilité de gestion opérationnelle, souvent couplé au coût total le plus économique de possession.
Quelle que soit la phase de développement de votre application Java, Azure fournit une solution cloud compatible pour répondre à vos besoins. Vous pouvez en savoir plus sur ces offres dans Déployer des applications Java avec confiance et facilité.
Portabilité complète pour vos applications Java : déployer en toute transparence n’importe où
Quel que soit le service Azure que vous choisissez pour votre application Java, la flexibilité de votre application est garantie. Étant donné que vous disposez du code Java et de ses sorties compilées, vous avez la liberté de déployer votre application partout où vous le souhaitez , qu’il s’agit de votre ordinateur de développement local, de vos serveurs de build, de vos environnements locaux ou de toute plateforme cloud de votre choix. La portabilité de votre application est entre vos mains.
Bien sûr, quand il y a tellement de choix, vous rencontrez un dilemme.
Dilemme : utiliser le service A ou B pour les applications Java
Si vous naviguez dans les offres d’Azure, vous pouvez rencontrer le dilemme de sélectionner le service Azure le plus approprié pour exécuter vos applications Java. Ce choix est crucial, car il influence votre planification des ressources, votre budget, votre projet chronologie s et, en fin de compte, le temps de votre application à commercialiser. La décision affecte non seulement les coûts de déploiement initiaux, mais également les dépenses de maintenance en cours.
Dans le passé, les organisations se sentaient souvent contraintes de choisir entre deux plateformes, technologies ou solutions concurrentes pour leurs applications logicielles. Par exemple, les organisations ont dû décider entre WebLogic ou WebSphere pour les applications Java Enterprise, Docker Swarm ou Kubernetes pour la gestion de conteneurs, ou les conteneurs par rapport aux machines virtuelles pour le déploiement. Ce processus décisionnel est appelé « État d’esprit A ou B », et il diffère considérablement des tests A/B, qui est une méthode permettant de comparer deux versions d’une page web ou d’une application les unes aux autres pour déterminer celle qui s’effectue mieux. Au lieu de cela, l’état d’esprit A ou B dans ce contexte consiste à choisir une plateforme ou une technologie sur une autre pour le déploiement d’applications. 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 empaquetés, des investissements initiaux substantiels dans l’infrastructure et la licence logicielle, ainsi que les longs délais nécessaires pour créer et déployer n’importe quelle plateforme d’application.
L’apport de cette mentalité à Azure peut entraîner un temps excessif consacré à la création d’une plateforme unique qui tente de prendre en charge toutes les applications, ce qui peut entraîner des retards et des inefficacités. Toutefois, Azure offre une approche plus avantageuse, encourageant un passage de cette mentalité restrictive à celle qui embrasse le meilleur des deux mondes, en fin de compte en produisant un meilleur retour sur investissement (ROI).
Lorsque vous passez à Azure, l’environnement cloud offre un paradigme flexible où vous pouvez approvisionner et déprovisionner des ressources en fonction de vos besoins, éliminant la nécessité de choisir entre un service sur un autre. Cette flexibilité nous amène dans l’approche A+B, une stratégie qui diffère de l’esprit traditionnel A ou B en encourageant un mode de pensée plus large et plus inclusif. Azure facilite ce changement en le rendant facile et économique pour fusionner les avantages de plusieurs services et adopter un état d’esprit A+B. Cette approche souligne le principe de sélection des services qui s’alignent le mieux sur les besoins spécifiques de votre application, qui préconisent essentiellement le choix de l’outil approprié pour le travail.
La transition vers un état d’esprit A+B permet aux organisations d’élargir leurs processus décisionnels et leurs stratégies techniques, en adoptant de nouvelles possibilités et opportunités que cette mentalité offre. Cet article délimite les principes de l’état d’esprit A+B, ce qui vous permet de sélectionner judicieusement les services Azure qui résonnent le plus efficacement avec les exigences de votre application. Qu’il s’agisse d’Azure Spring Apps, d’Azure App Service, d’Azure Container Apps (ACA), d’Azure Kubernetes Service ou de Machines Virtuelles, l’état d’esprit A+B vous permet d’évaluer et de choisir parmi un tableau de services Azure pour l’hébergement de vos applications. Cette philosophie s’applique universellement, transcendant les limites du langage et du framework. Bien que les applications Java soient le focus ici, 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 embrassant l’état d’esprit A+B, vous n’êtes pas limité à un seul service prédéterminé. Au lieu de cela, vous êtes autorisé à combiner des services d’une manière qui convient le mieux aux exigences uniques de votre application. Cette approche améliore non seulement la flexibilité et la scalabilité, mais optimise également 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 travaillez.
Pourquoi il n’est pas nécessaire de penser au service A ou B
Le choix du service cloud approprié pour vos applications n’a pas besoin d’être une décision binaire entre le service A ou le service B, grâce à la flexibilité et à l’étendue des options offertes par le cloud, en particulier avec Azure. Les sections suivantes décomposent pourquoi coller au choix traditionnel « un ou l’autre » n’est pas nécessaire et comment l’adoption d’une approche plus fluide peut bénéficier de vos opérations.
De vieilles habitudes à de nouvelles flexibilités
Traditionnellement, le déploiement de systèmes informatiques implique des investissements importants dans le matériel et les logiciels, ainsi que de longues durées d’installation. Cet environnement a rendu logique de sélectionner soigneusement une plateforme et d’optimiser tout autour de lui pour économiser sur les coûts et les ressources. Toutefois, l’environnement cloud, y compris Azure, introduit un changement de paradigme avec sa nature à la demande et élastique. Vous payez uniquement pour ce que vous utilisez et ajuster vos ressources pour répondre à vos besoins devient simple, sans le fardeau des dépenses d’investissement initiales.
Déplacement vers le cloud
Le passage au cloud et à Azure en particulier apporte un changement significatif dans la façon dont les responsabilités de l’infrastructure et de la plateforme sont gérées. Une grande partie de l’effort lourd, précédemment épaule par votre organisation, passe maintenant à Microsoft, comme illustré dans le diagramme suivant. Cette modification simplifie les opérations et réduit l’effort nécessaire pour gérer vos applications. Vous n’êtes pas lié par les contraintes de gestion de plusieurs plateformes, vous permettant de choisir le meilleur outil pour chaque travail 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 :
Choisir le meilleur ajustement pour chaque besoin
Dans ce nouveau monde centré sur le cloud, le processus décisionnel devient plus sur la sélection de l’outil approprié pour le bon travail, plutôt que d’essayer d’adapter tous vos besoins à un service prédéterminé. Qu’il s’agisse de choisir entre Azure Kubernetes Service et Azure Spring Apps pour les applications Spring Boot ou tout autre ensemble de services, le focus passe à ce qui répond le mieux aux exigences de chaque application spécifique.
L’essor des microservices
L’adoption des microservices prend davantage en charge cette approche flexible. Par conception, les microservices encouragent l’utilisation de la technologie la plus adaptée pour chaque service, favorisant une diversité technologique qui s’aligne naturellement sur l’esprit A+B. Cette approche consiste à utiliser les forces de différents services pour créer une architecture d’application plus robuste, efficace et évolutive.
Avantages de l’adoption d’A+B
L’adoption d’un état d’esprit A+B offre plusieurs avantages clés. Il permet une plus grande agilité et flexibilité, ce qui vous permet 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 également à raccourcir le temps de commercialisation de vos produits. En fin de compte, cette approche favorise l’excellence opérationnelle en alignant vos choix technologiques plus étroitement avec vos besoins et objectifs métier.
En résumé, le cloud et Azure en particulier offrent un nouveau moyen de réfléchir au déploiement et à la gestion de vos applications. En s’éloignant du choix restrictif A ou B et en embrassant l’état d’esprit A+B, vous pouvez prendre des décisions plus alignées sur les besoins spécifiques de vos applications, ce qui permet d’améliorer l’efficacité, l’agilité et les économies de coûts.
Conseils pratiques pour la transition vers l’état d’esprit A+B
La liste suivante énumère quelques principes clés que vous pouvez utiliser comme guide pour passer à l’état d’esprit A+B et poursuivre avec celui-ci :
Passez du cas d’usage à la solution, pas de l’autre façon. Souvent, de nombreuses équipes logicielles décident d’abord de la technologie, puis essaient de forcer l’ajustement des cas d’usage et de la conception. Dans de nombreux cas, cette approche entraîne une surcharge importante en termes de coûts, de temps de développement, de ressources et de dépenses opérationnelles. Obtenez de la clarté sur vos cas d’usage et vos exigences, à la fois fonctionnels et non fonctionnels, avant de passer à la solution.
Comprenez vos objectifs métier, la nature de l’entreprise et votre concurrence, et la fréquence à laquelle vous devez déployer de nouvelles fonctionnalités en production. Vous devez toujours concevoir votre solution pour répondre à vos objectifs et objectifs métier.
Comprendre les exigences de sécurité et de conformité. À l’âge du cloud, où tout est accessible sur Internet, la sécurité est cruciale et non négociée. En outre, selon le secteur que vous servez, votre application peut avoir besoin de répondre à certaines exigences de conformité. Vous devez concevoir votre solution pour répondre aux attaques avancées en matière de sécurité et répondre à vos exigences de conformité.
Comprendre votre budget et vos chronologie. Comprenez clairement votre budget pour le développement initial, les opérations en cours et les futures versions. En outre, comprenez vos chronologie. 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 pour répondre à votre budget et chronologie.
Pensez au cloud natif 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 natif, vous pouvez créer et déployer des applications en production à un rythme plus rapide. Le cloud fournit également des fonctionnalités qui peuvent ne pas être possibles localement , par exemple, l’élasticité, l’échelle mondiale, l’analytique avancée, l’IA et le Machine Learning (ML). Concevez votre solution en fonction des technologies natives cloud autant que possible.
Pensez à la culture DevOps. DevOps n’est pas seulement des outils ou des processus, il s’agit d’une pratique de développement logiciel qui favorise la collaboration entre le développement et les opérations, ce qui entraîne une livraison de logiciels plus rapide et plus fiable. Communément appelé culture, DevOps connecte les personnes, les processus et la technologie pour fournir une valeur continue.
Choisissez la solution qui répond à vos exigences professionnelles et non fonctionnelles, c’est-à-dire :
- Le plus rapide à implémenter.
- Rentable en termes de coûts liés à la compétence, à la création, au déploiement et aux opérations.
- Facile à utiliser.
- Entièrement compatible avec l’automatisation.
- Soutien de DevOps par conception.
Ces principes vous aident à garder votre focus là où il doit être - sur la création d’une solution qui répond à vos objectifs métier plutôt que de forcer l’ajustement de la solution à une plateforme prédéterminée.
Exceptions
Comme tout autre chose, il existe des exceptions à A+B. La liste suivante n’est pas exhaustive, mais elle vous fournit des conseils directionnels sur certaines exceptions que vous pouvez rencontrer :
Stratégie d’entreprise. Par exemple, certaines entreprises utilisent une adoption à l’échelle de l’entreprise des conteneurs pour créer et déployer des applications, car elles peuvent avoir plusieurs langages de programmation en lecture, et elles souhaitent créer et déployer toutes les applications de manière unifiée.
Trop loin dans la ligne avec l’exécution. Vous avez peut-être choisi une solution avant d’effectuer l’analyse A+B. Si vous êtes déjà profondément dans l’exécution de votre solution, poursuivez avec elle, mais pour l’application suivante, utilisez les principes de l’état d’esprit A+B pour choisir la solution appropriée pour votre cas d’usage.
Migrations de centres de données à grande échelle. Pour accélérer leur parcours vers le cloud, les entreprises utilisent généralement une stratégie appelée « lift-and-shift » qui implique la migration de serveurs (hébergeant leurs applications) en bloc vers Azure à l’aide d’outils comme Azure Migrate. Certaines utilisent cette approche pour migrer des centres de données vers Azure et les arrêter de manière efficace et rentable. Dans ce scénario, nous vous 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 destinations appropriées dans Azure pour vos applications. Ce n’est pas une taille qui s’adapte à tous. Ce n’est pas A ou B, mais A + B.
Le diagramme suivant récapitule les principales considérations relatives au choix d’un service Azure pour n’importe quelle application :
Comment choisir les services Azure appropriés pour vos applications Java
Pour simplifier le processus de sélection au milieu de 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 à leur service Azure optimal.
Au-delà des conseils pratiques pour prendre en compte les exigences non fonctionnelles, du point de vue technologique, la question initiale à considérer 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 les meilleurs itinéraires conseillés. La nature des applications , qu’elles soient basées sur Spring ou App Server, guide davantage la décision : les applications Spring s’alignent sur Azure Spring Apps, tandis qu’Azure App Service convient aux applications Tomcat ou JBoss EAP.
Pour ceux qui nécessitent un contrôle d’infrastructure, le choix dépend des préférences technologiques multiclouds : Azure Machines Virtuelles offre une transition simple, et pour ceux intégrés à Tanzu, les offres tanzu sur la place de marché IaaS sont idéales. Les clients investis dans Kubernetes ont les options d’Azure Kubernetes Service et d’Azure Red Hat OpenShift. Cette infrastructure de prise de décision est conçue pour simplifier les choix en associant les exigences des clients aux solutions les mieux adaptées à Azure.
Microsoft collabore avec de nombreux partenaires, y compris des partenaires dans les domaines suivants :
- Les principaux partenaires de l’écosystème Java, tels que Oracle, Broadcom, Red Hat, IBM et OpenAI.
- Organisations de base de données et d’outils clés, telles que MySQL, PostgreSQL, MongoDB Labs, DataStax, Redis Labs, Confluent et Elastic.
- Experts en observabilité, tels que New Relic, Dynatrace, AppDynamics, Grafana Labs et Datadog.
- Outils de développement, tels que IntelliJ, Maven et Gradle.
Notre investissement combiné permet d’élaborer des expériences de développement plus fluides, de garantir des intégrations transparentes avec des services essentiels tels que les bases de données, les caches, la messagerie et les répertoires, ainsi que fournir des outils complets pour l’observabilité. Grâce à l’automatisation, à l’équilibrage de charge et à la mise à l’échelle automatique, nous souhaitons assumer le fardeau de la gestion de l’infrastructure sur vos épaules. Cette prise en charge vous permet de vous concentrer sur la création de valeur métier par le biais de votre code, confiant dans les connaissances que les systèmes sous-jacents sont robustes et évolutifs. Pour ces raisons, nous vous recommandons d’utiliser des services Azure spécifiques pour héberger et exécuter vos types d’applications Java.
Déployer des applications Java en tant que fichiers source ou binaires
Pour les applications Java sur Azure, qu’elles soient déployées directement à partir du code source ou en tant que fichiers binaires compilés (fichiers JAR, WAR ou EAR), le déploiement est simplifié grâce aux offres de service complètes d’Azure conçues spécifiquement à ces fins. La portabilité inhérente des applications Java signifie qu’Azure peut fournir un large éventail de services pour répondre à vos stratégies de déploiement uniques et besoins opérationnels. Cette flexibilité garantit que quelles que soient les spécificités de votre application Java, il existe un service Azure qui s’adapte parfaitement à vos besoins.
Tenez compte des trois exemples suivants, qui montrent comment Azure répond à différents scénarios de déploiement d’applications Java :
Spring Applications. Pour les développeurs travaillant avec des applications Spring, Microsoft Azure a collaboré avec Tanzu by Broadcom, leader dans les projets open source Spring, pour offrir un service cloud premier appelé Azure Spring Apps. Cette collaboration améliore les expériences des développeurs en intégrant des outils de développement populaires comme IntelliJ, VS Code, Maven et Gradle, ainsi que des outils d’automatisation tels qu’Azure DevOps, GitHub Actions et Jenkins. Les outils d’observabilité tels que Application Recommandations, 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 la gestion des secrets et des certificats TLS/SSL, l’authentification « sans mot de passe » avec des services de stockage par le biais d’identités managées et le contrôle d’accès en fonction du rôle Azure (RBAC), ce qui garantit un processus de déploiement sécurisé et simplifié pour les applications Spring dans le cloud.
Applications Java sur JBoss EAP. De même, pour les applications Java utilisant JBoss EAP, il existe une expérience personnalisée grâce à la collaboration entre l’équipe Microsoft Azure et les équipes Red Hat JBoss EAP. Ce partenariat a entraîné une prise en charge améliorée sur Azure App Service, offrant un ensemble complet de fonctionnalités conçues pour les applications JBoss EAP. Cette prise en charge vous permet d’utiliser l’expertise combinée de Microsoft et Red Hat, ce qui garantit que vos applications Java s’exécutent en douceur, en toute sécurité et efficacement sur Azure.
Applications Java d’entreprise sur WebLogic. Les applications Java d’entreprise traditionnelles qui s’exécutent sur Oracle WebLogic ont également un chemin dédié à Azure. La collaboration entre Microsoft Azure et les équipes Oracle WebLogic a permis d’optimiser le déploiement sur Azure Machines Virtuelles. 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, fournissant une base solide pour les 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 la scalabilité et de la flexibilité de l’infrastructure Azure.
Ces scénarios mettent en évidence l’engagement d’Azure à offrir un environnement de déploiement flexible, sécurisé et efficace pour les applications Java, répondant à diverses infrastructures et architectures. Azure fournit également des services spécialisés pour d’autres applications Java, telles que celles qui s’exécutent 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 cloud fluide et productive en utilisant ces services Azure personnalisés, en automatisant et en sécurisant facilement leurs applications Java. Toutefois, le choix d’autres options de déploiement peut vous obliger à gérer vous-même la création et la maintenance de ces expériences de développeur et d’opérateur essentielles.
Le diagramme suivant montre les services Azure recommandés pour chaque type d’application Java déployé en tant que fichiers sources 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é en tant que fichiers sources ou binaires |
|---|---|
| Azure Spring Apps | Déployer une application Spring |
| 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 Machines Virtuelles Famille IBM WebSphere sur Azure Machines Virtuelles |
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 de conteneurs dans les entreprises. Le défi réside dans la création sécurisée et fiable de conteneurs, une étape cruciale pour fournir rapidement des applications logicielles de haute qualité et conteneurisées. Ce processus peut commencer à partir de zéro ou utiliser des systèmes de conteneur existants, en intégrant des outils qui compilent et stockent du code et des fichiers binaires pour simplifier les mises à jour et la gestion des conteneurs. Cette intégration est essentielle pour l’ajustement 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 par l’accélération de la livraison d’applications conteneurisées, mais également en fournissant des chemins clairs pour le déploiement à partir de sources ou de fichiers binaires. Cette approche double réduit l’impact sur les développeurs et améliore la charge des opérateurs d’infrastructure ou de plateforme. Étant donné la portabilité inhérente de Java, la vaste sélection de services de conteneur d’Azure garantit que vous trouvez la correspondance parfaite pour votre stratégie de déploiement et vos besoins.
Tenez compte des deux exemples suivants, qui montrent comment Azure répond aux scénarios de déploiement d’applications Java en conteneur :
Spring Applications. Azure Spring Apps est un excellent choix pour les applications Spring conteneurisées. Il prend en charge plusieurs types de déploiement, notamment les images sources, binaires ou conteneur. Cette flexibilité vous permet de passer facilement d’une méthode de déploiement à l’autre. Vous pouvez commencer par des conteneurs, mais décider ultérieurement de déployer en tant que sources ou fichiers binaires. Cette option est avantageuse, car elle contourne la nécessité de construire et de maintenance en continu des conteneurs, ce qui peut être fastidieux, répétitif et fastidieux.
Applications Java sur Tomcat. Azure App Service est adapté à la conteneurisation d’applications Java conçues pour s’exécuter sur Tomcat. Il s’adapte à différents types de déploiement, tels que des fichiers binaires ou des images conteneur. Comme Azure Spring Apps, ce service offre la possibilité d’alterner entre les stratégies de déploiement. Vous pouvez commencer par le déploiement de conteneur et gérer l’option permettant ultérieurement de basculer vers le déploiement de fichiers binaires (WAR et JAR). Cette polyvalence garantit que vous pouvez choisir la méthode de déploiement la plus efficace pour votre scénario spécifique, en rationalisant le processus de développement et de déploiement.
Ces exemples soulignent l’engagement d’Azure à fournir des environnements polyvalents, efficaces et conviviaux pour le déploiement d’applications Java, qu’il s’agisse de méthodes traditionnelles ou de conteneurisation moderne.
Le diagramme suivant 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 :
Résumé
Lors de la navigation dans le déploiement d’applications Java, Azure champions une approche A+B nuance, offrant un éventail de services adaptés pour répondre aux besoins de chaque application. La collaboration de Microsoft avec les leaders de l’écosystème Java a entraîné une suite de services Azure, chacune recommandée pour des types d’applications Java spécifiques , déployées en tant que sources, binaires ou conteneurs, rationalisant le processus de déploiement et garantissant des performances optimales. Ce focus sur la mise en correspondance des stratégies de déploiement avec les services Azure les plus appropriés souligne l’engagement de Microsoft à vous fournir la possibilité de choisir les outils appropriés pour le travail. La portabilité inhérente des applications Java est un avantage clé, ce qui permet une transition transparente entre les systèmes locaux et différents fournisseurs de cloud afin d’améliorer l’efficacité opérationnelle et l’agilité. En défendant ce processus de sélection plus large et plus inclusif, Microsoft simplifie non seulement le parcours cloud pour les applications Java, mais optimise également l’extensibilité, la sécurité, l’observabilité et l’efficacité des coûts. En fin de compte, les conseils de Microsoft permettent aux développeurs et aux entreprises d’utiliser l’écosystème d’Azure, ce qui garantit que chaque application Java se développe dans l’environnement cloud le mieux adapté à ses besoins.
Étape suivante
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