Transformer une app monolithique en microservices
Cet article s’adresse principalement à ceux qui, dans leur entreprise, réfléchissent à migrer des applications à l’ancienne dont, souvent, le code métier date d’une époque que ceux qui n’ont pas connu l’amstrad ne peuvent pas connaître. Pour les autres, vous apprendrez sans doute des trucs utiles sur les architectures logicielles d’un point de vue général, sur les micro-services et le tout avec une ébauche de solution proposée à l’aide de divers frameworks python.
Le défi de migrer des applications monolithiques
Évidemment, il n’y a pas de réponse absolue à ce type de problématique. Parfois, l’application est tout simplement mise à la poubelle et on recommence à partir de zéro, mais souvent, on ne souhaite pas tout virer et si possible, on essaye de récupérer des bouts de codes de l’application monolithique initiale pour les réutiliser. Alors comment faire, pour migrer une application dite monolithique de façon itérative, sans se prendre trop le front ?
Eh bien en découpant uniquement chaque partie de l’application dans des couches dédiées.
On distingue ainsi :
- le front, qui fournira l’interface utilisateur finale, souvent via l’utilisation d’un navigateur web ;
- le backend, qui fournit au front les informations métiers, généralement au travers d’un contrat d’interface qui est une API ;
- le code métier, qui traite avec des algorithmes des données et qui laisse généralement au backend la charge de les formater pour le front.
En schéma, cela quelque chose qui ressemblera grosso modo à ça :
Vous noterez que du côté du code métier, les portions de code sont séparées dans différents services. C’est le principe des micro-services. À chaque service son taf ! Et c’est là que ça devient intéressant. Si tout ou partie de portions de code peut être un service autonome, alors, sous réserve que l’on orchestre le workflow de traitement (d’appel des services dans un ordre précis), il est possible, de prendre des petits bouts de mon application initiale et de les migrer sereinement.
Pour cela, nous avons besoin de 2 choses :
- une API REST/SOAP ;
- un orchestrateur de tâche.
L'API REST / SOAP, contrat d'interface
L’API, qu’elle soit REST ou SOAP, est le passe-plat de l’orchestrateur de tâches. Son rôle sera toujours de demander à un orchestrateur de traiter des tâches et d’attendre que celui-ci retourne le résultat final après avoir demandé à plusieurs services de traiter des données.
L’API peut fournir un résultat de manière synchrone. Dans ce cas, on attend que toutes les tâches de l’orchestrateur se terminent et on récupère le résultat final.
Mais, il est aussi possible de récupérer des résultats manière asynchrone. Dans ce cas, on retournera un identifiant unique qui sera utilisé ultérieurement pour voir si le résultat final est prêt et le récupérer le moment venu.
En python, si on sort la grosse artillerie, on aura comme Framework Django.
Sinon, plus pragmatique et plus petit, le classique Flask ou encore FastAPI que j’affectionne tout particulièrement.
L'orchestrateur de tâches
Niveau orchestrateur, il existe une multitude de choix avec des solutions très bas niveau comme très haut niveau.
On attend principalement d’un orchestrateur qu’il soit simple à utiliser, qu’il gère des tâches, des workflows de tâches et qu’il nous permette de facilement monitorer tout ça, car qui dit workflow, dit complexité dans laquelle nous n’avons pas toujours envie de mettre la main.
Ici, par de solution miracle, des orchestrateurs, il y en a pour tous les goûts et toutes les sauces : ceux qui privilégient la rapidité, la scalabilité, le monitoring, la consommation de ressources.
Le choix dépendra vraiment de vos besoins et nécessitera forcément de vous projeter pour anticiper votre besoin !
Quelques noms :
- Celery ;
- Dramatic ;
- Dagster ;
- RedisQueue ;
- Airflow ;
- Prefect.
Dans tous les cas, il faudra prendre le temps de faire un audit, de retenir des solutions et de les étudier au cas par cas au regard de vos besoins.
Migrer votre application
Maintenant que nous avons nos acteurs, comment se passe une migration sereine ? Voici le schéma de principe qui vous évitera des mots de têtes et vous permettra d’itérer tranquillement sur la migration.
La migration se passe en itérations composées de 3 étapes :
1. Migrer/ ajouter / mettre à jour du code métier et créer un micro service unique qui sera connu de l’orchestrateur.
2. Au niveau de l’API, référencer votre micro-service en créant un endpoint qui lui sera unique et l’appeler via l’orchestrateur.
3. Enfin, remplacer le code métier migré par l’appel à l’API.
Comme une API REST ou SOAP est un protocole basique, même sur de très ancienne technologie, il reste facile d’appeler ce type d’API en remplacement d’un code métier. C’est justement toute la force d’utiliser principalement du REST ou du SOAP.
L'architecture en détails
Abordons une autre vue de chemin des données :
Ce qui intéressant dans cette vue, c’est qu’elle montre comment une donnée, traverse les différentes couches. Ce qu’il faut retenir via ce schéma :
- API: Il nous faut coder la signature de contrat :
- Niveau Orchestrateur : Il s’agit de le paramétrer en fonction de nos cas ;
- Au niveau du service : Il faut adapter (wrapper) la logique métier avec l’orchestrateur.
Enfin, voici le détail du schéma de principe résumé en une image :
Le mot de la fin
J’espère que cet article vous aura plus et vous aura aidé dans la compréhension du fonctionnement d’un environnement en microservices.
La partie, orchestration des microservices via par exemple, Kubernetes ou Docker Swarm n’a pas été abordé, car cette section est consubstantielle à une architecture en microservice mais évidemment si vous voulez en savoir, n’hésitez pas à aller voir ce qui se fait de ce côté-là.
