Récemment, j'ai suivi un streaming de la conférence de Neal Ford dans le cadre de JavaOne. Pour être honnête, le discours n'était pas quelque chose d'époustouflant, de nombreux outils qu'il montrait étaient dépassés ou pas du tout les meilleurs, mais il a déclaré un fait très important: les serveurs d'applications sont destinés à remédier à la rareté des ressources en partageant les ressources (qui ne sont plus rares de nos jours).
Rappelez-vous il y a 10 ans quand nous devions commander du matériel 6 mois à l'avance? À ce moment-là, toutes les applications web étaient déployées sur le même serveur d'applications (et n'étaient pas toujours en cluster). Après quelques années, j'ai remarqué que les serveurs d'applications augmentaient en nombre. Certains devaient même être regroupés parce que nous ne pouvions pas nous permettre le service offert. C'était le moment où les gens ont commencé à réfléchir sur quel serveur d'application l'application est à déployer, et ce selon leur profil de charge spécifique. Au cours des dernières années, un nouveau comportement est apparu: le déploiement d'une seule application Web sur un seul serveur d'applications car il était jugé trop important pour être potentiellement non affectée par d'autres applications sur le même serveur. Et cela conduisait parfois à la pratique de faire cela pour chaque application, que celle-ci soit considérée comme critique ou non.
De nos jours, le matériel est disponible instantanément, en quantité requise et pour rien: ils l'appellent le Cloud. Alors pourquoi utilisons-nous encore des serveurs d'applications? Je pense que les gens derrière le cadre du framework Spring se sont posé la même question et ont trouvé une réponse radicale: nous n'en avons pas besoin. Spring a toujours été autours du développement pragmatique quand JavaEE (appelé alors J2EE) était encore un gros standard gonflé, plein d'acronymes barbares et pénible à développer (souvenez-vous d'EJB 2.0?) - pas étonnant que tant de développeurs critique la plateforme. Spring a favorisé des conteneurs JSP / Servlet simples sur des serveurs JavaEE entièrement compatibles et maintenant (via SpringBoot) plus aucun serveur externe n'est nécessaire.
Quand j'en ai entendu parler pour la première fois, j'étais stupéfait, mais à l'ère des micro-services, je suppose que cela a beaucoup de sens. Imaginez que vous venez de développer votre application. Au lieu de créer un WAR, un EAR ou n'importe quel autre package que vous générer normalement, il vous suffit de faire un push sur un dépôt Git. Ensuite, "un listener" pousse le code sur le serveur, arrête l'application existante et la redémarre. Ce ne serait pas seulement amusant mais vraiment Agile / Devops. C'est exactement le genre de déploiement de Spring Boot. Ce n'est pas la seule caractéristique de Spring Boot, mais il fournit également une véritable convention sur la configuration, un Maven POM utile, des métriques originales et des contrôles de qualité et bien plus encore, mais le plus important c'est le serveur Tomcat Embarqué .
De l'autre côté, les grands firmes comme IBM, Oracle et même Red Hat investissent encore énormément d'argent dans le développement de leurs serveurs d'applications compatibles Java EE. Ce qui est amusant, c'est que pour être compatible avec JavaEE, vous devez implémenter des modules «intéressants» tels que Java Connector Architecture, que j'ai vu une seule fois au début de ma carrière pour me connecter à un CICS.
Maintenant, seul l'avenir dira ce qui se passera ensuite (même si on voit bien une tendance qui ne cesse de monter)
Aucun commentaire