Microservices ou pas microservices ?

Microservice, WTF ?

Comme cela arrive parfois dans la tech, un nouveau terme “disruptif” est popularisé, et souvent utilisé à tort et à travers. Essayons de le définir au mieux.

Développer un projet avec des microservices, cela signifie découper son application en plusieurs services indépendants, chacun ayant une responsabilité propre.

Le principal objectif de cette approche est de répartir et isoler les responsabilités. Chaque équipe contribue sur une brique fonctionnelle, et s’accorde avec les autres équipes sur les entrée/sorties de son service. Tant que le contrat d’entrées sorties est respecté, les développeurs ont une certaine flexibilité de procéder comme ils le souhaitent pour répondre à l’objectif. En cas de défaillance, une plus petite partie du système est affectée. De manière similaire, les déploiements sont moins risqués car on diminue l’impact des changements sur le système.

Cette séparation des charges permet de faire facilement cohabiter plusieurs langages, les services communiquant en général entre eux par APIs. Les endpoints HTTP sont implémentables facilement dans n’importe quelle stack technique, la dépendance à un seul langage ou une seule stack technique est donc faible, ce qui réduit le temps nécessaire de montée en compétences.

Un microservice bien conçu assure un seul rôle au sein d’une application. Par exemple, dans le cas d’un site e-commerce, un service sera responsable de gérer l’authentification d’un utilisateur, un autre d’afficher les promotions en cours, un autre de gérer le panier, etc. Dès lors, chaque service est beaucoup plus simple qu’un monolithe, il est donc beaucoup plus facile pour un développeur de rentrer dans le sujet et de contribuer.

Enfin, en terme de montée en charge, il est possible de répartir les ressources matérielles selon la charge nécessaire à chaque service, ce qui permet une consommation au plus près des besoins réels.

Tout le monde n’est pas Uber

Il semblerait de prime abord que les microservices n’aient que des avantages. Alors pourquoi ne pas se lancer tête baissée ?

Comme souvent, l’utilisation de nouveaux outils augmente la complexité du système en général. Diviser une application en une multitude de composants apporte de la simplicité au sein des services ainsi créés, mais la complexité du système en général est significativement augmentée. De multiples services peuvent signifier de multiples types de bases de données, ce qui peut compliquer la gestion des transactions. La gestion des logs est également un vrai sujet : comment centraliser et organiser la collecte de logs d’une dizaine de services, dans des technologies différentes ? Comment faire avec 50 ? Et comment rester efficace en assurant une couverture de tests complète ?

Par ailleurs, l'approche microservices amène parfois à oublier les contraintes propres aux systèmes distribués : la latence n’est pas nulle, le traffic réseau n’est pas gratuit et infini, la topologie n’est pas constante…

On serait tenté ici d’avoir recours à cette fameuse phrase : tout le monde n’est pas {Google, Uber, Facebook...}. L’approche microservice est intéressante dans les grandes organisations de développement, c’est-à-dire d’après moi s’il est possible d’affecter au moins 5 développeurs sur une même sous-partie du système. En-dessous de ce seuil, pour les entreprises ou les équipes de petite taille dont l’avantage compétitif est la possibilité de créer et d’itérer rapidement, cette approche peut se révéler contre productive.

Pour des projets nécessitant moins d’une centaine de jours hommes, les framework web modernes offrent des systèmes intégrés permettant de gérer facilement et de manière prêt à l’emploi des éléments clés comme l’authentification, les dépendances, voire même des modules de back office. En quelques heures voire quelques minutes, les fondations d’un projet peuvent être dressées.

La cohabitation est possible

Heureusement, vous n’avez pas forcément à choisir votre camp tout de suite. En effet, la frontière entre les deux approches n’est pas aussi fermée que celles du monde réel en période de pandémie, et il est possible de tester le meilleur des deux approches simultanément. Il est parfaitement faisable, même si le cœur de votre application est développé sur un framework monolithique, d’avoir recours à une approche microservices partielle.

Avec Google Cloud Platform il est par exemple possible de :

• déporter une partie des traitements dans des Cloud Function, qui permettent dans le langage majeur de votre choix de réaliser des traitements asynchrones
• gérer des fils de messages avec Pub/Sub, système hautement résilient qui retiendra vos messages tant qu’ils ne sont pas traités. Cela peut être une solution pour parer aux défaillances de votre monolithe

Pour éviter de faire exploser la complexité de vos applications, pourquoi ne pas commencer avec cette double approche ?