Types de déploiement d’application

Effectué

Il existe plusieurs façons de déployer des applications Java dans le cloud. Cette unité examine les différentes options afin que, dans l’unité suivante, vous puissiez mieux comprendre les services proposés par Azure.

Machines virtuelles, conteneurs ou PaaS ?

La principale question consiste à déterminer si vous voulez ou avez besoin de déployer votre application sur une machine virtuelle, dans un conteneur ou sous forme de solution PaaS (platform as a service).

  • Avec les machines virtuelles, vous êtes dans un monde similaire à un environnement de centre de données local ou classique. Azure fournit un ensemble de machines virtuelles préconfigurées qui exécutent les principaux systèmes d’exploitation (Windows et Linux). Vous avez alors besoin de configurer et gérer ces machines.

    Nous vous suggérons d’adopter cette solution pour commencer, car elle est la plus proche de celle que la plupart des entreprises utilisent déjà avant de migrer vers le cloud. Les entreprises installent généralement leur propre logiciel de gestion de la configuration, leur version préférée de Java, et elles peuvent alors exécuter leur charge de travail Java comme auparavant.

    La solution des machines virtuelles fonctionne bien si vous avez une équipe des opérations expérimentée qui va les configurer et les gérer, et si vos cas d’usage sont spécifiques. Par exemple, vous utilisez peut-être des bibliothèques natives ou des logiciels propriétaires, comme Oracle WebLogic Server ou IBM WebSphere Application Server.

  • Avec les conteneurs, vous avez encore la majeure partie du contrôle que vous avez avec les machines virtuelles, mais les efforts sont moindres en matière d’opérations. Vous pouvez installer votre propre Machine virtuelle Java (JVM) ou un logiciel spécifique. Vos conteneurs seront exécutés soit localement, soit chez un fournisseur de services cloud.

    Étant donné que les conteneurs offrent beaucoup de liberté, ils rencontrent certains problèmes identiques à ceux des machines virtuelles. Si vous fournissez votre propre JVM, vous devez la mettre à jour et la corriger, le cas échéant. Ainsi, les images Docker nécessitent une bonne chaîne d’outils d’intégration continue et livraison continue (CI/CD) pour gérer correctement les conteneurs. Comme les images Docker peuvent s’exécuter localement et sont plus légères que les machines virtuelles, elles offrent également une expérience de développement exceptionnelle.

  • Avec une solution platform as a service, le fournisseur de services cloud gère la majeure partie du travail de maintenance et des opérations. Les mises à jour du système d’exploitation, les correctifs Java, la sécurité et la conformité sont tous fournis. Par conséquent, cette option est généralement plus sécurisée et moins coûteuse. Elle est également fournie avec certaines fonctionnalités de scalabilité, qui peuvent permettent à votre application de mieux s’adapter aux besoins de vos clients. Les performances en charge s’en retrouvent aussi améliorées et les coûts sont réduits quand le trafic est moindre.

    Vous pouvez aller plus loin avec une solution PaaS. Vous pouvez définir une configuration automatique, gérer et charger des secrets (par exemple, avec Azure Key Vault), superviser votre application, lancer une session de profilage en temps réel et assurer un déploiement sans temps d’arrêt.

Options de déploiement

Que vous utilisiez des machines virtuelles, des conteneurs ou une solution PaaS, vous pouvez généralement déployer vos applications Java sur le cloud de deux manières :

  • Déploiement du code source : vous commitez votre code source dans un dépôt Git, puis le fournisseur de services cloud exécute un processus qui compile, génère et empaquette l’application.
  • Déploiement d’un fichier JAR, WAR ou EAR : Vous empaquetez votre application, généralement sous forme de fichier JAR exécutable (Java ARchive), mais les formats WAR (Web Application ARchive), EAR (Enterprise Application ARchive) et d’autres sont également possibles. Le fournisseur de cloud exécute ensuite le fichier exécutable.

Ces deux options de déploiement sont des méthodes classiques d’exécution d’applications Java. Le processus de build est généralement similaire pour les deux options. La principale différence réside dans l’emplacement où il s’exécute. Il est plus simple de laisser le fournisseur de services cloud s’en occuper, et appliquer ses propres vérifications et correctifs de sécurité. Un processus de build local de l’application ou avec une plateforme CI/CD, comme GitHub Actions, offre davantage de flexibilité et de contrôle.

Fonctions serverless

Les fonctions serverless, ou plus particulièrement Azure Functions, correspondent à une combinaison des différentes solutions examinées, avec une caractéristique très spécifique : elles sont conçues pour s’exécuter pendant de courtes périodes. En règle générale, une fonction est déclenchée par un événement, comme une requête HTTP, et reste « chaude » pendant quelques minutes, jusqu’à ce qu’elle repasse en mode veille.

Les fonctions partagent certaines caractéristiques avec la solution PaaS décrite plus haut. Dans Azure, notre solution PaaS (Azure App Service) et notre solution serverless (Azure Functions) sont techniquement similaires et partagent du code et des services communs.

En ce qui concerne les options de déploiement, les fonctions utilisent généralement des fichiers JAR. D’autres options, comme Docker, sont disponibles, mais elles sont moins appréciées et ne fonctionnent généralement pas très bien. Cela est dû au fait que la plateforme sous-jacente ne parvient pas à les optimiser de la même façon que des fichiers JAR.

En substance, les fonctions serverless ont besoin d’être spécifiquement codées. Leurs fonctionnalités dépendent du fournisseur de cloud sur lequel elles s’exécutent, et leur durée de vie réduite complique l’utilisation de solutions traditionnelles comme la mise en cache ou la réplication de session HTTP.

Les fonctions serverless se mettent bien à l’échelle et offrent le meilleur prix pour les environnements peu utilisés. En même temps, elles peuvent répondre aux chargements de trafic les plus exigeants.