Comment migrer d’un monolith vers des microservices Partie 1 : Introduction aux microservices

Convaincu que les modèles monolithiques possèdent des limites, nous avons accompagné nos clients qui les ont rencontrées dans leur migrations vers des systèmes en microservices avec succès. L’objectif de cette série d’articles est de fournir une méthodologie pour anticiper et organiser la migration du point de vue architectural, d’exploitation et organisationnel.

Cet article est le premier d’une série dédiée à la migration, les liens seront mis à jour au fur et à mesure des publications.

Beaucoup d’entreprises possèdent un système monolithique qui fonctionne. Une partie de ces entreprises est satisfaite par ce modèle et ne rencontre pas de problème particulier. Cet article s’adresse à l’autre partie qui, en grandissant, a fait grandir ses applicatifs et rencontre certains des problèmes suivants :

  • en heure de pointe, les applicatifs sont ralentis suite à la détection de problèmes de performance,
  • Les applications ne traitent plus les messages en temps réel,
  • Les services back-end sont fortement couplés au travers de connexions synchrones (effet spaghetti) et rendent difficile les tests de nouvelles features et de non régression,
  • Malgré la maturité du service informatique vis à vis du métier, la vitesse de déploiement des nouveaux services est ralentie,
  • Les équipes atteignent des tailles critiques et leur gestion est de plus en plus difficile et coûteuse,
  • Le turnover des développeurs travaillant sur l’application est de plus en plus important,
  • La montée en compétence des nouveaux entrants est très complexe.

La dernière décennie a vu se généraliser un nouveau courant qui est celui des micro-services. Beaucoup d’entreprises le voient comme un effet de mode lancé par Netflix et Amazon. Pourtant, celles qui l’ont -correctement- adoptée ont bénéficié des avantages qu’ils procurent et ne se voient pas revenir à un système classique.

En effet, l’architecture en microservices permet d’augmenter l’agilité des développements (time to market), la scalabilité du SI (absorption de la charge sans diminution du temps de réponse) et facilite l’expérimentation et le test des nouveaux services.

Il est difficile de se préparer seul lorsqu’on manque d’expérience. Comme l’a dit un célèbre poète:

“Tout le monde a un plan jusqu’au premier coup-de-poing dans la face”.  Mike Tyson

Cet article a pour vocation de fournir une méthodologie pour la migration depuis un système monolithique vers des microservices.

Mais d’abord, qu’est ce que le microservice ?

“Quand plusieurs éléments travaillent ensemble pour un objectif précis, de grands exploits peuvent être accomplis. On rapporte qu’un lionceau succomba sous un rassemblement de fourmis.”  Saskya Pandita

Sasky Pandita l’a bien compris, on est plus fort en travaillant en groupe. Pour définir un microservice, on utilisera le même principe que celui d’Unix.
Ainsi, un microservice est caractérisé par : “Do one thing and do it well” (Linus Torvald). Il faut partir d’un besoin métier, l’isoler des autres et préciser le besoin d’un point de vue fonctionnel. Les méthodologies de Domaine Driven Design peuvent aider à effectuer cela.

Techniquement, voici un exemple d’un microservice type avec deux types d’entrée/sortie (API REST et API d’une message queue) :

Plus généralement, un microservice est composé:

  • D’une logique métier, un service qui est effectué, comme par exemple, la réalisation des factures. Cette partie, la plus importante, représente le cœur du traitement de la donnée.
  • De sa propre base de donnée indépendante des autres services.
  • D’une API lui permettant de communiquer avec les autres microservices.Les APIs sont des interfaces agnostiques du langage de programmation utilisé.
    Dans l’exemple, on dispose d’une API :
    –  permettant de requêter une queue de messages (Kafka par exemple) pour recevoir les données de taxation.
    –  pour exposer les informations en base de données aux services extérieurs
    –  pour communiquer ces informations en temps réel via la queue de sortie aux services externes qui en ont besoin pour créer/modifier leurs propres données (SAV par exemple).

Une fourmi ne peut rien faire seule, un module unix non plus, et de la même manière, un microservice perd de sa valeur seul dans un système.


Comment interagissent les microservices ?

Les microservices travaillent ensemble pour délivrer des informations pertinentes au client. Un système composé de plusieurs microservices, avec les bons outils d’exploitation (Containerisation et orchestration), pourra réaliser des merveilles de réactivité attendues.

C’est dans la collaboration que la majorité des challenges commencent. Parmi les plus récurrents :

  • Le déploiement des applications : Celui-ci doit se faire de manière automatique, permettre de se mettre à l’échelle lorsque la charge augmente ou diminue pour un microservice. Le processus de déploiement doit pouvoir reconstruire à la volée l’ensemble du système.
  • La découverte des services (Service Discovery): Pour fonctionner ensemble, chaque microservice doit savoir à qui s’adresser. Les microservices ne sont pas assignés à une adresse fixe comme une IP ou un Host de manière statique. Les orchestrateurs comme DC/OS ou Kubernetes permettent de gérer ce type de problème.
  • Communication avec le Legacy : On ne passe pas d’un monolith à un système de microservices d’un coup, et on doit pouvoir se connecter au legacy sans y être fortement dépendant. L’adhérence avec le legacy doit se faire de manière asynchrone afin de limiter les échecs en cascade.
    Et bien d’autres challenges.

 

Maintenant que nous voulons franchir le pas, comment réussir cette migration ? Dans le prochain article de cette série, nous allons voir la manière dont les microservices communiquent , et rentrerons dans les détails des méthodologies de déploiement.

 

Ismail Hrimech & Younes Azoum