Existe-t-il un futur pour les serveurs d’applications ?

Si l’on entend beaucoup moins parlé de serveur d’application, on remarque toutefois que presque toutes les entreprises en ont. Une forte base existante, certes. Mais bien que je ne sois pas en train de les déclarer morts et enterrés, il faut bien admettre que les serveurs d’applications n’affichent pas une courbe de croissance ascendante.

Les serveurs d’applications ont connu leur heure de gloire dans les années 90s, lorsque les entreprises ont commencé à migrer d’une architecture client-serveur vers une approche d’architecture n-tiers. Les entreprises achetaient alors de grands serveurs physiques à des constructeurs comme Sun Microsystems et, pour optimiser leur investissement, elles devaient justement y migrer leur applications reposant sur la mécanique client-serveur. Cela a finalement débouché sur ce que nous connaissons, les serveurs d’applications – Java EE étant le premier exemple. Chez Microsoft, Windows Server était à la fois OS et serveur d’application.

La première difficulté provoquée par les serveurs d’applications : la dégradation de performance. Une application pouvait affecter les performances d’une autre, en partageant les mêmes ressources d’un serveur physique.

Mais aujourd’hui, les architectures ont considérablement évolué. La couche hardware sous-jacente s’est retrouvée dissimulée dans une couche d’abstraction, grâce à la virtualisation et aux conteneurs. Les applications quant à elles ont été découplées en services. Tout ce que nous déployons est désormais plus petit ; les déployer offre plus de flexibilité et moins de dépendances.

Pourquoi donc déployer des bibliothèques pour communiquer avec un système de messaging si le composant fonctionnel n’en a pas besoin ? Ainsi est notre quotidien : aujourd’hui, il n’est plus nécessaire d’avoir recours à des serveurs d’application où chaque bibliothèque, même inutile, est déployée. Au lieu de cela,  on peut utiliser des langages de scripts (comme Python et Node.JS), des frameworks pouvant être déployés à l’usage, des serveurs ultra-légers ou encore des frameworks pour Java comme Jetty et Spring.io.

Au final, la question est donc : avez-vous besoin d’un serveur d’applications traditionnel. La  réponse : cela se pourrait.

En tant qu’architecture, je sais par expérience qu’il est de plus en plus difficile de réunir un ensemble de composants et d’appeler cela une application. Une telle approche nécessite des bases de données, des services et des APIs partagés. Ainsi, il apparait donc que les serveurs d’applications soient quelque peu datés.

Et en même temps, il existe plein de situations où les composants ne sont pas partagés, où le dimensionnement à l’échelle du Web n’est pas nécessaire et où les compétences Java EE sont bien présentes. Pourquoi donc ne pas continuer à utiliser son serveur Tomcat ou WebLogic dans ce cas ? Sans oublier le fait qu’il existe encore nombre d’applications tierces qui requièrent Java EE pour fonctionner.   

Traduit et adapté par la rédaction