Architectures micro-services : les monolithes ne sont pas une fatalité

Après un break de 3 ans, en 2014, le client a souhaité que j'intervienne en tant qu'architecte / tech lead sur un nouveau projet. Évidemment, nous nous somme fait plaisir en y mettant tous les derniers frameworks à la mode et une interface utilisateur dernier cri (basée sur Angular 1.x et Bootstrap). Projet fini et succès en poche, il était temps de revenir à ce monolithe avec cette idée folle de tout refaire.

La problématique

L'application en question est vieille de 15 ans, toujours développée de la même manière, mais avec une multitude d'intervenants, aussi bien internes qu'externes. Les technologies utilisées sont Java et Struts 1.x , framework de persistance improbable et qui présente beaucoup de procédures stockées. Bref, le bonheur absolu autant pour le développeur (Quoi ?! Il y a encore des projets en production avec cette techno ?) que pour l'utilisateur (avec le "blanc" lors du rafraîchissement des pages), ou encore pour le responsable d'application (problèmes de sécurité, staffing, coûts de maintenance, etc.). Après presque 3 ans, je suis sorti de ce projet car j'estimais avoir fait le tour et surtout, je n'en pouvais plus !

Malgré tout, c'est une bonne expérience avec de belles rencontres et j'avais toujours en tête qu'il fallait arrêter cette façon de faire. Je me suis ainsi décidé à réécrire cet applicatif.  Après un break de 3 ans, en 2014, le client a souhaité que j'intervienne en tant qu'architecte / tech lead sur un nouveau projet. Évidemment, nous nous somme fait plaisir en y mettant tous les derniers frameworks à la mode et une interface utilisateur dernier cri (basée sur Angular 1.x et Bootstrap). Projet fini et succès en poche, il était temps de revenir à ce monolithe avec cette idée folle de tout refaire.  

La solution : l'architecture micro-services

Faire autrement, oui, mais comment ? Un arrêt des développements pour une période de réécriture de plusieurs mois n'est pas possible. Puis, j'ai eu l'occasion d'assister aux conférences Devoxx à Paris en 2014 qui traitaient notamment de l'architecture micro-services. Une de ces présentations était un retour d'expérience sur la réécriture d'un projet complet en utilisant les micro-services. La solution était là devant moi !

C'était la meilleure approche pour enfin en finir avec ces cycles de développement lourds et longs du monolithe : faire plus petit, beaucoup plus petit, par morceaux indépendants. Je me suis donc formé sur l'architecture micro-services, préparé les environnements et fait une sorte d'évangélisation auprès des différents acteurs. Une nouvelle demande business nous arriva. Il s'agissait de tracer les échanges des différents utilisateurs de l'application. Nous tenions alors une opportunité de prouver que c'était faisable. Je me suis donc lancé dans l'écriture d'une nouvelle application qui ne s'occuperait que de ce besoin bien précis et qui viendrait se greffer sur le monolithe.

Une application Angular venant s'exécuter par dessus la vieille application Struts. Un soir où j'étais en cours de finalisation de mon POC (proof of concept), la responsable du projet a pu voir l'intégration des deux projets ensemble. Je lui ai montré le nouvel onglet sur le côté gauche de l'application existante ; lorsque l'on clique dessus, un panneau vient glisser au-dessus pour dévoiler toutes les fonctionnalités de ce module de communication. Elle était agréablement surprise du résultat et voyait enfin la preuve que l'on pouvait effectivement faire différemment. Il ne restait plus qu'à mettre en place la partie back-end avec tous les composants nécessaires pour faire tourner ce genre d'architecture et embarquer l'équipe infrastructure dans l'aventure.  

Aujourd'hui, 25 micro-services et 2 applications Angular (1.x et 5) tournent sur cette plateforme et ce n'est que le début !