Au début des années 2000, quand j’ai commencé à travailler, les serveurs d’applications Java étaient à la mode.
Aujourd’hui, ils sont en voie de disparition, et quand on prononce le mot "J2EE" (ou Java EE comme on dit maintenant), c’est surtout pour évoquer des promesses déçues et des projets terminés dans la douleur.
En repensant à cette époque, je me suis rendu compte d’une chose : certes les spécifications et les produits présentaient beaucoup de problèmes, mais de nombreuses approches qu’on critiquait alors se sont révélées les bonnes sur le long terme.
Je ne veux pas dire que toutes les idées étaient bonnes : certaines étaient franchement mauvaises, et n’auraient jamais pu fonctionner même dans le meilleur de mondes. La multiplication des nouveautés était en elle-même source de difficultés, même les éditeurs le disent.
Si vous êtes un·e jeune développeur·euse, pour qui J2EE évoque une époque lointaine et mystérieuse, comme le Jurassique ou le septennat de Valéry Giscard d’Estaing, cet article vous permettra de comprendre pourquoi les personnes étaient aussi enthousiastes à l’époque, et pourquoi il·elle·s sont parfois un peu dubitatif·ve·s face aux promesses de nouvelles technologies.
Si vous êtes une personne qui a vécu cette époque et qui utilise peut-être encore ces technologies, il vous éclairera sur les nouvelles approches utilisées aujourd’hui. Cela pourrait vous donner des idées sur la manière dont on peut désormais répondre à des besoins que vous avez renoncé à satisfaire.
Dans l’article, je mélange fonctionnalités J2EE et fonctionnalités qui ne sont pas J2EE mais qui sont fournies par la plupart des serveurs d’applications d’entreprise. Je me permets de le faire pour deux raisons :
JNDI permettait de spécifier des paramètres à passer aux applications depuis le serveur. Cela aurait dû permettre de redéployer le même artefact de la recette à la production sans avoir à lui adjoindre de fichiers de configuration spécifiques à chaque étape.
Pourquoi ça ne fonctionnait pas ?
Aujourd’hui : c’est la même approche choisie par Docker via les variables d’environnement ou le service discovery, et les outils se sont modernisés pour s’y adapter.
À l’arrivée des serveurs d’applications, le web était l’avenir, et la manière d’y aller était la scalabilité horizontale. L’approche en vogue consistant à remplacer les mainframes par des fermes de serveurs Unix, moins puissants mais beaucoup moins chers.
Pour limiter la complexité induite par la multiplication des machines, l’idée est de gérer un ensemble de serveurs vus comme une ressource unique et non plus des machines une par une.
Il y avait trois manières de faire du clustering : matériel, fournis par les systèmes d’exploitation, et par les serveurs d’applications.
Le clustering matériel et OS était plus lourd à mettre en œuvre et plus coûteux, il était donc plutôt réservé aux fonctions de stockage, alors que pour les traitements, on préférait essayer de s’appuyer sur les serveurs d’applications.
Pourquoi ça ne fonctionnait pas ?
En pratique, il s’agissait surtout d’être conservateur en utilisant au mieux un nombre limité de machines, avec comme objectif premier la redondance pour éviter les pannes.
Aujourd’hui, si les mainframes sont toujours là, les serveurs Unix eux sont en train de faire leur sortie. Les serveurs x86 qui les ont remplacés sont beaucoup plus puissants pour le même prix, et l’automatisation et la virtualisation permettent plus facilement d’ajouter des serveurs. La scalabilité n’est pas gérée au niveau des serveurs d’applications mais par l’infrastructure et les outils : proxys, réseau… La simplification des architectures ajoutée à l’industrialisation ont permis d’atteindre la cible.
Les serveurs fournissaient une gestion de session au niveau du cluster, l’équivalent d’un outil NoSQL intégré.
Pourquoi ça ne fonctionnait pas ?
Au final, on utilisait beaucoup l’affinité de session, c’est-à-dire la capacité à lier une session à un serveur en particulier.
Aujourd’hui : on a appris à stocker le minimum dans une session voire à s’en passer, et des solutions NoSQL sont matures et permettent de répondre aux besoins.
Comme on l’a déjà dit, les machines de l’époque coûtaient cher. Pour mutualiser la consommation de mémoire, il était possible de déployer plusieurs applications dans un serveur d’applications. Cette approche était aussi beaucoup utilisée pour limiter les coûts de licences.
Pourquoi ça ne fonctionnait pas ?
L’isolation de composants n’était pas à la hauteur :
Aujourd’hui : on mutualise toujours. La différence est que l’augmentation de la mémoire des serveurs permet de le faire plus "bas" qu’au niveau du serveur : après la phase "une VM pour chaque application", les conteneurs ont la même approche, et les problèmes d’isolation sont de retour.
Pour éviter les interruptions de services, les serveurs auraient du pouvoir faire des bascules à chaud sur une nouvelle version d’une application. Sur le papier, l’idée était prometteuse : le serveur routait les nouvelles requêtes sur la nouvelle version, en laissant les requêtes en cours d’exécution se terminer, puis décommissionnait l’ancienne version quand plus aucune requête ne l’utilisait.
Ce déploiement et cette bascule étaient même cluster-aware : les artefacts étaient déployés automatiquement sur tous les nœuds du groupe de serveurs.
Pourquoi c’était peu utilisé ?
Aujourd’hui : les pratiques ops ont beaucoup évolué mais certains problèmes de fuite mémoire sont toujours là. Au final, la bascule se fait plutôt par des proxys réseau qu’au niveau d’un serveur.
Reste parfois le soucis des modèles de données, même si les pratiques se sont améliorées et que le NoSQL apporte des réponses.
Les EJBs sont un moyen de packager des groupes de fonctionnalités dans un artefact en exposant une façade normée sous forme de services. L’idée était de permettre de développer des applications complexes en composants des briques élémentaires bien séparées avec des appels transactionnels entre elles tout en permettant de masquer la localisation. C’était l’équivalent des annuaires de services qu’on retrouve aujourd’hui dans les microservices. Lorsque les EJBs étaient déployés ensemble, les appels se faisaient localement, ce qui permettait d’économiser la latence réseau en conservant l’isolation.
Pourquoi ça ne fonctionnait pas ?
Aujourd’hui : les microservices vont dans la même direction en s’appuyant sur d’autres protocoles. Les avancées dans les pratiques de découpage métier comme DDD, ou l’approche REST qui consiste à exposer uniquement des ressources, peuvent faire en sorte que les résultats soient meilleurs.
JAAS est la partie sécurité de J2EE, elle permet de faire du contrôle d’accès au niveau des services, par annotations ou à l’aide de XML. Cela permet de gérer la sécurité de manière déclarative.
Pourquoi ça ne fonctionnait pas ?
Aujourd’hui : JAAS est remplacé par des frameworks plus léger comme Spring Security, qui peuvent s’appuyer sur JAAS suivant les cas mais qui en masquent les limites.
La JVM était lente à démarrer, les applications lentes à déployer, et J2EE rendait difficile d’écrire du code facile à tester hors du serveur. Pour accélérer le cycle le développement, l’idée était de permettre un redéploiement à chaud de l’application sans avoir à tout recharger pour que le·a développeur·se ne soit pas interrompu·e dans son travail.
Pourquoi ça ne fonctionnait pas ?
Au final, la meilleure approche était de s’en passer, quitte à ajouter des couches d’indirections pour isoler artificiellement le code.
Aujourd’hui, la JVM et les serveurs d’applications ont été optimisés et les processeurs vont beaucoup plus vite. JEE de son côté a pris en compte ces problèmes et permet aujourd’hui de tester hors serveur.
Les alternatives à JEE tels que DropWizard ou Spring sont d’ailleurs encore plus rapides.
Les limites qui ont causé la nécessité d’avoir cette fonctionnalité ayant disparues, elle est désormais inutile.
Cette revue permet de dégager deux choses :
Beaucoup d’idées ont échoué pour cause de maturité autant, voire plus, que pour des raisons techniques.
Ensuite, les serveurs d’applications essayaient de résoudre beaucoup de problèmes tout seuls. Aujourd’hui, les solutions sont réparties à différents niveaux de la stack : de l’OS à la configuration réseau. Les causes sont multiples : nouvelles technologies, normalisation de l’utilisation de plusieurs langages, baisses des prix des serveurs … Cela permet de diminuer la complexité de ce qui est demandé aux stack applicatives et donc de faciliter l’adoption de nouvelles technologies. Cela veut aussi dire que les serveurs d’applications à l’ancienne sont désormais un poids mort dans un SI.
Les principales raisons de les conserver aujourd’hui sont le coût de la migration, les questions de licences et de support, et potentiellement l’intégration avec le reste de l’écosystème de l’éditeur.
Avec le temps qui passe et le mûrissement des alternatives plus légère comme Spring ou DropWizard, la force de ces arguments diminue petit à petit. En attendant que le serverless ou une autre approche les rendent à leur tour obsolètes.
Espérons que les serveurs d’applications pourront bientôt profiter de leur retraite bien méritée.