Il y a quelque temps déjà, la RAM et l'espace disque étaient des ressources rares. À cette époque, la stratégie répandue consistait à héberger différentes applications sur la même plate-forme. C'était l'âge d'or du serveur d'applications. J'ai écrit dans un article précédent que la tendance actuelle vers des ressources moins chères le rendrait obsolète, à court ou à long terme. Cependant, une tendance technologique pourrait le ramener en faveur.
Avoir un serveur d'application est bon quand les ressources d'infrastructure sont chères, et les partager entre les applications apporte une réduction significative des coûts. De l'autre côté, il faut un aperçu approfondi de la charge de toutes les applications partageant les mêmes ressources, ainsi que des administrateurs système qualifiés. Lorsque les coûts d'infrastructure diminuent, on commence à voir apparaître la paresse et l'aversion au risque, et l'hébergement d'une seule application sur un serveur d'applications devient la norme.
À ce stade, la prochaine étape logique consiste à déterminer pourquoi les serveurs d'applications en tant que composants dédiés sont toujours requis. Il semble que les gens de Spring sont arrivés à la même conclusion, car le mode par défaut des applications Spring Boot est de compresser les fichiers JAR exécutables - également connus sous le nom de Fat JARs. Ces applications peuvent être exécutées en tant que java -jar fat.jar. D'où la fameuse citation : Make JAR, not WAR
Je ne suis pas complètement convaincu, car je pense que cela écarte trop facilement l'expertise de la plupart des équipes d'Ops en matière de gestion des serveurs d'applications. Cependant, un argument convaincant sur les Fat JARs est que la technologie de Boot est en charge de l'application dès son lancement. Elle peut gérer les classes de chargement (loader) de la façon dont elle veut. Par exemple, avec l'aide d'une boîte à outils, une des classes peut être changée et rechargée sans redémarrer toute la JVM - une astuce qui donne un retour rapide à chaque changement de code.
On pense à tort que les fournisseurs de serveurs d'applications étaient toujours aux prises avec l'héritage. Wildlfy, TomEE et d'autres serveurs d'applications peuvent également être configurés pour empaqueter des fichiers JAR Fat mais avec une énorme différence : Il n'y a rien de tel que Spring Dev Tools, pour le reste, il est toujours nécessaire de redémarrer le serveur lorsque le code change. La seule alternative pour une rétroaction plus rapide sur ces changements est un plugin avec un niveau inférieur, par ex. JRebel avec des licences pour toute l'équipe. Cependant, il y a toujours une raison d'utiliser les archives de WAR, et cette raison est Docker. En fournissant une image Docker du serveur d'applications commune en tant qu'image de base, il suffit d'ajouter un fichier WAR au-dessus, ce qui rend l'image WAR assez légère. Et ceci ne peut pas être réalisé (encore) via l'approche JAR.
Notez que ce n'est pas Spring Boot vs JavaEE, mais surtout JAR vs WAR. Spring Boot est parfaitement capable d'interpréter n'importe quel format, et de nombreux fournisseurs de serveurs d'applications le font aussi. Comme je l'ai souligné ci-dessus, la seule différence est que le permier rechargera les classes au lieu de redémarrer toute la JVM lorsqu'un changement se produit - mais je crois que cela arrivera à un moment donné pour les autres aussi. Le choix entre les approches WAR et JAR est fortement dépendant du fait qu'une entreprise valorise des cycles de feedback plus rapides au cours du développement ou des images Docker plus optimisées et gérables.
Aucun commentaire