Microservices : avantages, inconvénients et mythes

Auteur du billet de blog : Nicolas Hilaire - Neotech Solutions

Nicolas Hilaire

Consultant .NET
  Publié le lundi 23 janvier 2017

Artisan logiciel particulièrement intéressé par les technologies .NET. Polyvalent et curieux, je suis néanmoins à l'écoute des autres technologies du marché. MVP (Microsoft Most Valuable Professional) de 2007 à 2014, je suis également auteur d'un ouvrage pour apprendre le C#, à destination des débutants et de plusieurs MOOCs sur le C#, Windows Phone ou ASP.NET MVC...

Les microservices sont très à la mode en ce moment, au détriment des applications dites monolithique. Wikipédia les décrit comme :

un style d'architecture logicielle à partir duquel un ensemble complexe d'applications est décomposé en plusieurs processus indépendants et faiblement couplés, souvent spécialisés dans une seule tâche. Les processus indépendants communiquent les uns avec les autres en utilisant des API langage-agnostiques.


Mais avant de vous lancer tête baissée dans cette nouvelle mode, voici quelques éléments de réflexion à prendre en compte sur les avantages, inconvénients et mythes de ces architectures.

 

Qu'est-ce qu'un microservice ?

Commençons par lister les avantages qui sont souvent mis en avant lors des conférences. Un microservice vous permet en théorie :

  • d'avoir du code isolé qui permet de résoudre un problème métier spécifique
  • d'être créé par des petites équipes (agiles si possible) utilisant potentiellement des technologies différentes pour résoudre au mieux le problème (.NET, nodejs, etc.)
  • d'être exposé des fonctionnalités via un contrat d'API
  • d'être souvent dépendant d'autres services, mais continue à fonctionner quand les dépendances ne fonctionnent plus
  • d'être être mis à jour indépendamment et mis à l'échelle indépendamment

Plus les services sont découpés, plus on s'approche d'une architecture dite micro-services.

Des choses intéressantes, plus ou moins vraies. Faisons un petit tour d’horizon des avantages, les vrais.

 

Avantages

Voici les avantages qui doivent être déterminants pour vos besoins, avant de vous lancer dans une approche microservices.

  • Mise à l'échelle indépendante
  • Possibilité d'utiliser plusieurs socles techniques par service (par exemple une base de données NoSql avec du NodeJs d'un côté, une api web ASP.NET core de l'autre, ...)
  • Déploiement indépendant (mise à jour d'un service sans déployer tout le reste). Par contre, attention aux tests d'intégrations, a-t’on bien testé que la V2 d’un service fonctionne toujours pour ses consommateurs ?
  • On peut utiliser des versions différentes de dépendances dans des services différents (bibliothèques, version de produits, etc.)

 

Mythes 

Dans un microservice, le périmètre de code est réduit, donc plus facile à comprendre et à maintenir.

C’est vrai, mais en fait nous savons faire ça depuis des années avec la programmation orientée objet et des bonnes pratiques de développement (SOLID, etc.). On peut découper du code en petites assemblies aussi dans une application monolithique. Bien sûr, l'approche microservices force à réaliser ce découpage, mais avec des bons développeurs disciplinés cela est également possible. A contrario, si on modifie une méthode ou quoi que ce soit dans une assembly d'une application monolithique, alors le compilateur peut nous prévenir si on casse un contrat, ce que l’on n’a pas avec des micro-services complètement indépendants.

Si un service ne fonctionne plus, alors il n'impacte pas les autres services. 

En général, les services ont souvent des dépendances vers d'autres services afin de pouvoir être complètement opérationnels. Du coup, pour se prémunir des pannes d'autres services, il faut écrire du code spécifique (gestion des erreurs, gestion du timeout, retry pattern, circuit breaker, etc.). Ce code ajoute de la complexité, diminue la lisiblité et rend le vrai code métier plus difficile à tester. En général, pour tenter d’éviter les pannes, on déploie plusieurs instances d'un service ce qui permet de limiter les erreurs transitoires, alors que dans une application monolithique, si l'appli est down, on n’a pas à prévoir de code pour la restaurer, il faut la remettre en route.

 

Inconvénients

Il y a pas mal d’inconvénients à prendre en compte dans les approches microservices, en voici quelques-uns.

  • Vous n’avez pas d’IntelliSense lors des appels entre services. Le refactoring devient d’autant plus compliqué. Et vous n’avez pas de vérification de types à la compilation non plus.
  • La communication inter-service passe par des appels réseau, plus couteux qu'en mémoire (temps réseau, sérialisation/désérialisation), surtout si on commence à appliquer des pattern retry.
  • Les performances seront forcément moins bonnes. Attention à la congestion du réseau. De même, les temps d'appels peuvent être imprévisibles (timeout ou pas)
  • Les appels réseau sont potentiellement non fiables, donc il faut prévoir des mécanismes pour y remédier (pattern retry, circuit breakers, …). Et du coup, le code serveur doit être idempotent. Que se passe-t'il si on fait un appel pour faire un paiement, qu'il est un peu plus long que d'habitude, qu'on a tenté un retry et que le paiement passe deux fois ?
  • Les appels entre les services peuvent avoir besoin d'authentification, surtout s’ils sont dans des réseaux différents, d’autorisation ou d’encryption. Cela augmente évidemment la complexité.
  • Le debugging devient compliqué, surtout si ça vient de problèmes réseaux ou matériels. Il faut une bonne gestion de logs, de monitoring, etc.

 

Conclusion

En conclusion, l’approche microservices augmente drastiquement la complexité. Il faut donc que les avantages soient vraiment importants et qu’ils justifient clairement tous les désavantages pour s'y lancer. Cela peut avoir beaucoup de sens pour des entreprises comme Netflix ou Amazon, dont les besoins en scalabilité sont primordiaux ; mais pour votre besoin, est-ce le cas ?

Pesez bien le pour et le contre.