Est-il toujours judicieux de choisir une architecture en microservices ?
L'architecture en microservices est en vogue depuis un moment, et pour cause, de grandes entreprises en ont prouvé son efficacité telle que Google, Amazon ou encore Netflix. Au vu de ces succès, de plus en plus d’applications utilisent cette architecture qui semble si prometteuse, mais est-ce toujours le bon choix ?
Les microservices
L'avantage principal des microservices est leur indépendance les uns avec les autres. En effet, les microservices sont comme des LEGO®, ils s’emboîtent les uns avec les autres afin de former un produit final. Si nous voulons modifier une brique, il suffit de la remplacer, le changement est rapide et nous n’avons pas besoin de toucher au reste des briques. Dans le cadre des microservices, nous allons redéployer un service avec nos modifications : une mise en production peut donc se faire tout en restant totalement transparent aux yeux des utilisateurs.
Dans cet exemple simplifié, nous pouvons voir que le serveur back est divisé en trois microservices :
- Un service permettant de gérer les connexions;
- Un service permettant de gérer la plateforme e-commerce;
- Un service permettant de gérer les commandes.
Le service e-commerce est instancié 3 fois car il y a de l’influence sur le site. Il est possible d’ajuster les instances en fonction de la charge de chacune, afin d'avoir un coût d’utilisation optimal ainsi que des risques limités à certaines fonctionnalités de l'application.
La deuxième particularité est le fait d’avoir 3 bases de données différentes. Il est bien sûr possible d’avoir une seule base de données mais les schémas doivent être séparés pour bien garder la séparation entre microservices et en garder tous les avantages. Cela signifie qu'il faudra, soit dupliquer les données, soit aller chercher les données en faisant communiquer les services entre eux.
Pourquoi dois-je m’en méfier ?
Vous vous êtes sûrement rendu compte, en énumérant la liste des avantages, qu’il y a toujours des inconvénients qui viennent avec… Valent-ils toujours le coup par rapport aux avantages qu’ils rapportent donc ?
Les contraintes
La première contrainte, que je vous ai évoqué est le fait d’avoir plusieurs schémas de données indépendantes à chaque microservice. Il vous faudra donc faire des choix techniques en fonction de l’utilisation de la donnée, et surtout implémenter des fonctions supplémentaires pour aller mettre à jour les autres services ou récupérer les informations nécessaires. À noter qu’il vous faudra alors probablement gérer des transactions à travers plusieurs microservices afin de ne pas avoir d’incohérences en cas d’erreur dans un des microservices.
La deuxième contrainte est liée au déploiement de l’application. Il vous faudra mettre en place le déploiement de tous vos services et vous assurer qu’ils sont bien capables de communiquer entre eux. Le déploiement continu est fortement recommandé mais sa configuration en sera beaucoup plus complexe.
Enfin, il faut prendre en compte la complexité du maintien de l'application. En effet les logs seront éparpillés dans différents projets, il y aura aussi plus de tests à effectuer qu’une application monolithique.
Alors, que choisir ?
Pour répondre à cette question il faudra d'abord que vous définissiez comment va évoluer votre produit ? Sachez d'abord que rien n'est figé et n'ayez pas de trop grosses ambitions dès le début : le principe de Pareto s’applique parfaitement dans ce cas (20% de votre travail représentera 80% des résultats).
Une fois votre conception bien claire, si vous projetez que vous aurez beaucoup de fonctionnalités différentes qui risquent de s’ajouter à votre application au fil du temps ou beaucoup de fonctionnalités de base sont essentielles à l’application dans le cadre de votre Minimum Viable Product, les avantages des microservices se feront ressentir dès le début, ne vous posez pas de questions et foncez.
Par contre, si vous vous rendez compte que l’application est concentrée sur deux ou trois fonctionnalités maximum, que vous ne voyez pas d'autres fonctionnalités indispensables à l’avenir, une application monolithique est totalement suffisante et les avantages des microservices seront moindres comparés aux contraintes engendrées.
À noter qu’il est toujours possible de faire évoluer une application monolithique vers des microservices mais cela demandera un travail considérable si l’architecture de base de l’application monolithique n’est pas bien structurée. En revanche, si vous partez sur une application monolithique petite et bien structurée en vue de futures évolutions, cela se fera très rapidement et sans grosses surprises. Pour moi il est essentiel de garder un découpage en fonctionnalités dans une application monolithique, en vue de futures évolutions mais également pour garder de la maintenabilité sur votre projet.
En résumé
Utilisez des microservices pour une application qui contient beaucoup de fonctionnalités indépendantes les unes des autres ou qui possède un réel besoin d’évolution à moyen terme. Au contraire si votre projet n’a pas beaucoup de fonctionnalités et qu’il est difficile d'imaginer de grosses évolutions, l’application monolithique sera beaucoup plus avantageuse.
— Kevin Messiaen, développeur full-stack, Nextoo
