Et si votre architecture "microservices" était en réalité un monolithe distribué

/ 22 July 2022 / 0 Comments

Lorsqu'un certain nombre de conditions ne sont pas remplies (connaissance de l'application, pratiques d'ingénierie, culture, …), il est fréquent que notre intention de mettre en place une architecture "microservices" donne, en réalité, naissance à un monolithe distribué.

❓ Pourquoi un monolithe distribué est un pb ?

Car nous avons les inconvénients des 2 architectures sans les avantages :

la lourdeur et la rigidité des monolithes
la complexité opérationnelle des microservices

Un monolithe distribué rend l’implantation d’un changement très complexe et coûteux, pire que pour un monolithe classique. Nous sommes donc très loin de l'objectif fondamental d'une architecture "microservices" qui est de faciliter l’implantation des changements.

❓ Quels sont les signes qui doivent vous alerter ?

Les services sont étroitement couplés :
- Couplage comportemental : Exiger qu'une dépendance soit disponible pour accomplir une tâche
- Couplage temporel : Nécessité une communication rapide et à faible latence avec d'autres services
- Couplage d'implémentation : Devoir changer plusieurs services suite au changement d'un seul service
Vos microservices sont trop bavards
Les mêmes développeurs travaillent sur de nombreux microservices
Beaucoup de vos microservices partagent un magasin de données
Vos microservices partagent une grande partie du même code ou des mêmes modèles

Je ne dis pas que si votre système coche l'une de ces cases, vous avez un problème… il y a toujours des exceptions. 😉 Mais si vous vous reconnaissez sur un certain nombre de points ci-dessus, il est probable que vous soyez en présence d'un monolithe distribué.

Ne tardez pas pour agir ! C’est une spirale descendante.