Considération sur l'Architecture en Microservices

Voila la nouvelle voie de l'architecture applicative ! Les microservices vont révolutionner votre SI et diminuer drastiquement les coûts, réduire les temps de développements bref que du bonheur. Mouais faut relativiser, c'est comme tout, faut-il encore bien le faire. Par ce que bon depuis le temps, je suis pas certain que nous les "nouvelles technologie" aient permis de retrouver la productivité, la performance et la fiabilité des bon vieux Mainframe !

Enfin bon moi je suis dans la nouvelle tech alors parlons un peu des microservices. Un petit tour sur Wikipedia et divers sources et on retient :

• L'architecture en microservice est une architecture applicative que l'on peut rapprocher d'une architecture n-tiers.  
• Elle n'est pas en concurrence avec une approche SOA car orienté application et non système d'information : seuls les microservice de "haut niveau" sont exposés au SI et ceci dans le respect des règles de la SOA.

Une telle architecture permettrait de donner de la flexibilité non plus au niveau d'un SI (où règne la SOA) mais au niveau d'un applicatif. Ainsi si une fonctionnalité est très consommatrice en ressource pourquoi ne pas la coder dans un technologie plus efficiente comme en GO ou en C ou encore clusteriser le service...  Cette flexibilité technologique aussi de construire un composant  de l'application avec par exemple une application NodeJS existante (genre NodeRed).

Côté humain, pour que cela fonctionne il vous faut une équipe de superman multi techno, et puis côté production c'est la panique alors une alternative est de passer le tout sous Docker... donc ça veut dire qu'en fin de développement une bonne part du travail de l'exploitation est réalisé. Alors là va falloir soit briser les barrières entre les développeurs et les exploitants, ce qui n'est pas évident... entre les uns qui subissent les bugs des autres, les autres disent que les uns veulent juste presser UN bouton... c'est pas gagné. OK ce qu'il vous faut c'est une équipe de super DevOps comme on dit, mouais va falloir les trouver les petits gars, piquer quelques ressource chez OVH et Google et c'est parti. C'est fou comme tout de suite ça devient moins réaliste.

Côté infrastructure, au lieu d'avoir un découpage par API au sein d'une application on a un découpage de service, de services exposés sur le réseau. Cela sous entend qu'ajouter un passage sur le réseau n'est pas un problème pour vous, bande passante démesurée et latence faible... bon aujourd'hui ça se trouve facilement. En suite vous aurez un surconsommation de mémoire et de CPU par rapport à une application monolithique :

• Le passage par le réseau va nécessiter une sérialisation et dé-sérialisation (CPU) ce qui grosso-modo entraîne un pique x4 de la trace mémoire qui sera absorbé par les garbage collector ou autre gestionnaire de mémoire (CPU).
• Mutualisation des API tiers dans un application monolithique et du serveur d'application (Jboss ou autre). 
  

Après une réalité économique est que les coûts du CPU, de la mémoire, du le réseau diminuent rapidement avec le temps alors que le coût de la main d'œuvre augmente (j'aimerais qu'il augmente un peu plus). Donc l'architecture en microservices a du sens. Bien utilisé certains pensent même que cela pourrait mettre à défaut la loi de Brooks, ce dont je doute mais c'est le rêve de tout chef de projet, parfois ils rêvent éveillés, mais attention au réveil le bilan est souvent lourd...