Les micro services peuvent-ils remplacer les serveurs d’applications ?

Un concept en fin de vie ?

Durant ces dix dernières années, particulièrement dans l’écosystème Java, le serveur d’applications fut le roi. Tout bout de code « server side » finissait fatalement déployé sur cet élément hautement important du système d’information. Comme nous l’enseignons nous-mêmes en formation son rôle est de fournir les services techniques aux applications (connexions aux bases de données, gestion du cycle de vie des composants, module d’authentification, supervision des transactions…) déchargeant ainsi les développeurs de l’implémentation de cette tuyauterie ; tâche critique et souvent difficile.

Cette séparation des responsabilités est au cœur de la philosophie Java EE, la spécification de la plateforme distingue en permanence les activités incombant aux développeurs d’applications de celles prises en charge par les administrateurs gérant l’infrastructure ou encore justement les fonctionnalités devant être assurées par le serveur d’applications.

Si on peut comprendre cette logique, pensée pour les environnements complexes des grandes organisations où le SI est géré de manière centralisée, cette approche souffre néanmoins d’une rigidité et d’une lourdeur certaine, chaque application nécessite avant d’être déployée que l’on paramètre son environnement technique sur son conteneur.

Les micro services

Les micro services s’inscrivent dans une démarche opposée : la notion de serveur d’applications (conteneur) gouvernant l’exécution des composants d’application déployés en son sein n’existe plus. Chaque micro service est une application « standalone » tournant dans son propre processus. Ces applications communiquent entre elles au travers de web services de type REST sans l’intermédiation d’un middleware devenu encombrant, à la manière des commandes Unix qui s’agrègent avec un simple pipe. Leur périmètre est généralement réduit, elles font une chose et s’attachent à bien le faire, ainsi on pourra les réécrire si nécessaire complètement en limitant les coûts.

REST a montré qu’il était néfaste de chercher à s’abstraire coûte que coûte du protocole HTTP, les micro services nous enseignent qu’il n’est sans doute pas optimal de chercher à effacer le système d’exploitation comme les serveurs d’applications Java se sont évertués à le faire, en voulant recréer un OS dans l’OS.

Les frameworks

Qui dit nouveaux paradigmes dit nouveaux frameworks. Toujours dans l’univers Java, il y a bien sûr le presque déjà vieux Playframework qui adopte une stratégie résolument de rupture en proposant une pile logicielle avant-gardiste et encourageant fortement l’usage du langage Scala, même si Java est également supporté. Un autre framework, bien que moins audacieux, mérite tout autant que l’on s’y intéresse, il s’agit de Dropwizard. Ce framework possède l’avantage de capitaliser sur des technologies matures, bien connues des développeurs Java EE comme Jersey, Jackson, Jetty ou encore Hibernate validator. La courbe d’apprentissage sera donc douce.

Allez bonne année et RDV en 2013 pour mettre tout ceci en pratique !