Convaincu que les modèles monolithiques possèdent des limites, nous effectuons dans le cadre de projets, des migrations vers des systèmes en microservices avec succès. L’objectif de cet article est de fournir une méthodologie pour anticiper et organiser la migration du point de vue architectural, d’exploitation et organisationnel.
Quels problèmes peut-on rencontrer lors de migrations vers des systèmes en microservice ?
Beaucoup d’entreprises possèdent un système monolithique qui fonctionne. La plupart des entreprises se disent satisfaites et ne rencontrent aucun 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, le ralentissement des applicatifs 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, le ralentissement de la vitesse de déploiement des nouveaux services,
- 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.
Souvent se préparer seul lorsque manque d’expérience devient difficile. 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, la composition d’un microservice est :
- une logique métier, un service effectué, comme la réalisation des factures. Cette partie, la plus importante, représente le cœur du traitement de la donnée.
- sa propre base de donnée indépendante des autres services.
- 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.
Spécialiste de sujets liés aux Architecture Reactives, j’ai travaillé sur de nombreux projets stratégiques de refonte SI impliquant plusieurs métiers. Je suis également passionné par les sujets liés à l’Agile, je contribue d’ailleurs au blog Organisation Performante.
N’hésitez pas à me faire un retour sur cet article ou à me contacter sur LinkedIn pour partager nos actualités!
Nidhal
Laisser un commentaire