Une question intéressante. Ce n'est que mon avis sur le sujet, alors prenez tout avec un grain de sel. J'ai parfois déployé et géré des applications en utilisant à la fois des conteneurs de servlets et des serveurs intégrés. Je suis sûr qu'il y a encore de nombreuses bonnes raisons d'utiliser des conteneurs de servlet, mais je vais essayer de me concentrer uniquement sur les raisons pour lesquelles ils sont moins populaires aujourd'hui.
Version courte: les conteneurs de servlets sont parfaits pour gérer plusieurs applications sur un seul hôte, mais ne semblent pas très utiles pour gérer une seule application. Avec les environnements cloud, une seule application par machine virtuelle semble préférable et plus courante. Les frameworks modernes veulent être compatibles avec le cloud, d'où le passage aux serveurs embarqués.
Je pense donc que les services cloud sont la principale raison de l'abandon des conteneurs de servlets. Tout comme les conteneurs de servlets vous permettent de gérer les applications, les services cloud vous permettent de gérer les machines virtuelles, les instances, le stockage de données et bien plus encore. Cela semble plus compliqué, mais avec les environnements cloud, il y a eu un passage aux machines à application unique. Cela signifie que vous pouvez souvent traiter l'ensemble de la machine comme si c'était l' application. Chaque application s'exécute sur une machine de taille appropriée. Les instances cloud peuvent apparaître et disparaître à tout moment, ce qui est idéal pour la mise à l'échelle. Si une application a besoin de plus de ressources, vous créez plus d'instances.
Les serveurs dédiés, en revanche, sont généralement puissants mais de taille fixe, vous exécutez donc plusieurs applications sur une seule machine pour maximiser l'utilisation des ressources. Gérer des dizaines d'applications - chacune avec ses propres configurations, serveurs Web, routes et connexions, etc. - n'est pas amusant, donc l'utilisation d'un conteneur de servlet vous aide à garder tout gérable et sain d'esprit. Il est cependant plus difficile à l'échelle. Les conteneurs de servlets dans le cloud ne semblent pas très utiles. Ils devraient être configurés pour chaque petite instance, sans apporter beaucoup de valeur puisqu'ils ne gèrent qu'une seule application.
De plus, les nuages sont cool et les choses non-cloud sont ennuyeuses (si nous en croyons toujours le battage médiatique). De nombreux frameworks essaient d'être évolutifs par défaut, afin de pouvoir être facilement déployés dans les clouds. Les serveurs intégrés sont rapides à déployer et à exécuter, ils semblent donc être une solution raisonnable. Les conteneurs de servlet sont généralement toujours pris en charge mais nécessitent une configuration plus compliquée.
Quelques autres points:
- Le serveur embarqué pourrait être optimisé pour le framework ou mieux intégré aux outils du framework (comme la console de jeu par exemple).
- Tous les environnements cloud ne sont pas livrés avec des images de machine personnalisables. Au lieu d'écrire des scripts d'initialisation pour télécharger et configurer des conteneurs de servlet, l'utilisation d'un logiciel dédié pour les déploiements d'applications cloud est beaucoup plus simple.
- Je n'ai pas encore trouvé de configuration Tomcat qui ne vous salue pas avec une erreur d'espace de génération permanente tous les quelques redéploiements de votre application. Prendre un peu plus de temps pour (redémarrer) les serveurs intégrés n'est pas un problème lorsque vous pouvez presque instantanément basculer entre les instances de préparation et de production sans aucun temps d'arrêt.
- Comme déjà mentionné dans la question, il est très pratique pour l'utilisateur final d'exécuter simplement l'application.
- Les serveurs intégrés sont portables et pratiques pour le développement. Aujourd'hui tout est rapide , les prototypes et les MVP doivent être créés et livrés le plus rapidement possible. Personne ne veut passer trop de temps à configurer un environnement pour chaque développeur.