Types de déploiement d’applications

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

Machines virtuelles, conteneurs ou plateforme en tant que service ?

La principale question est de savoir si vous souhaitez ou devez déployer votre application sur une machine virtuelle, à l’intérieur d’un conteneur ou en tant que solution PaaS (Platform as a Service).

• Avec des machines virtuelles, vous êtes dans un monde similaire à un environnement 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), et vous devez configurer et gérer ces machines.

  Nous vous suggérons d’adopter cette solution initialement, car elle est la plus proche de ce que la plupart des entreprises utilisent déjà avant de passer au cloud. Ils installent généralement leur propre logiciel de gestion de la configuration, installent leur version préférée de Java et peuvent ensuite exécuter leur charge de travail Java d’une manière similaire à la façon dont ils l’ont fait dans le passé.

  La solution de machine virtuelle fonctionne bien si vous disposez d’une équipe d’opérations expérimenté qui les configure et les conserve, et si vous avez des cas d’usage spécifiques. Par exemple, vous pouvez utiliser certaines bibliothèques natives ou certains logiciels propriétaires, tels qu’Oracle WebLogic Server ou IBM WebSphere Application Server.

• Avec les conteneurs, vous avez toujours la plupart du contrôle que vous avez avec des machines virtuelles, mais avec moins d’efforts d’opérations. Vous pouvez installer votre propre machine virtuelle Java (JVM) ou un logiciel spécifique, et vos conteneurs s’exécutent localement ou sur n’importe quel fournisseur de cloud.

  Étant donné que les conteneurs offrent beaucoup de liberté, ils souffrent de certains des mêmes problèmes que les machines virtuelles. Si vous fournissez votre propre machine virtuelle JVM, vous devez la mettre à jour et la corriger si nécessaire. Par conséquent, les images Docker nécessitent une bonne chaîne d’outils d’intégration continue et de livraison continue (CI/CD) pour gérer correctement les conteneurs. Étant donné que les images Docker peuvent s’exécuter localement et sont plus légères que les machines virtuelles, elles offrent également une excellente expérience de développement.

• Avec une solution de plateforme en tant que service , le fournisseur de cloud gère la plupart des charges de maintenance et d’exploitation. 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. Il est également fourni avec certaines fonctionnalités d’extensibilité, qui doivent permettre à votre application de s’adapter mieux aux besoins de vos clients. Cela entraîne également de meilleures performances en termes de charge et de moindre coût lorsqu’il y a moins de trafic.

  Vous pouvez obtenir plus d’informations à l’aide d’une solution PaaS. Vous pouvez configurer la configuration automatique, gérer et charger des secrets (par exemple, à l’aide d’Azure Key Vault), surveiller votre application, lancer une session de profilage en direct et activer le 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 dans le cloud de deux façons :

• Déploiement de code source : vous validez votre code source dans un référentiel Git et le fournisseur de cloud exécute un processus qui compile, génère et packages l’application.
• Déploiement de fichiers JAR, WAR ou EAR : vous empaquetez votre application, généralement en tant que fichier JAR exécutable (Java ARchive), mais WAR (Application web ARchive), EAR (Application d’entreprise ARchive) et d’autres formats de fichier 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 pour exécuter des applications Java. Pour les deux options, le processus de génération est généralement similaire et la principale différence réside dans l’exécution de ce processus. Laisser le fournisseur de cloud effectuer la build est plus simple, et avec cette approche, le fournisseur de cloud applique ses propres contrôles de sécurité et correctifs. En créant l’application localement ou à l’aide d’une plateforme CI/CD telle que GitHub Actions, vous bénéficiez d’une plus grande flexibilité et d’un contrôle.

Fonctions sans serveur

Les fonctions serverless, ou plus spécifiquement Azure Functions, sont un mélange de différentes solutions que nous avons vues et offrent une fonctionnalité très spécifique : les fonctions serverless sont destinées à s’exécuter pendant de courtes périodes de temps. En règle générale, une fonction est réveillée par un événement, tel qu’une requête HTTP, et elle reste « chaude » pendant quelques minutes jusqu’à ce qu’elle revient en veille.

Fonctions partagent des fonctionnalités avec la solution PaaS que nous avons décrite précédemment. 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.

Pour les options de déploiement, les fonctions fonctionnent généralement avec des fichiers JAR. D’autres options telles que Docker sont disponibles, mais elles sont moins populaires et ne fonctionnent généralement pas aussi bien. Cela est dû au fait que la plateforme sous-jacente ne peut pas les optimiser de la même façon que pour les fichiers JAR.

Par leur nature, les fonctions serverless doivent être spécifiquement codées. Leurs fonctionnalités dépendent du fournisseur de cloud sur lequel ils s’exécutent, et leur courte durée de vie complique l’utilisation de solutions traditionnelles telles que la mise en cache ou la réplication de session HTTP.

Les fonctions serverless peuvent être mises à l’échelle et offrent le meilleur prix pour les environnements à faible utilisation. En même temps, ils peuvent répondre aux charges de trafic les plus exigeantes.