Remarque : cet article n’est pas une tentative pour inciter les lecteurs à choisir ou non des microservices. Au lieu de cela, j’essaie de combler certaines lacunes dans les informations relatives aux microservices, afin que le lecteur puisse prendre une décision éclairée.
Il est difficile, voire impossible, d’ignorer le battage médiatique des microservices. Chaque jour, on peut voir de plus en plus de contenu décrivant à quel point le concept de microservices est bon et avancé. Quiconque n’implémente pas de microservices doit commencer à les faire immédiatement, quels modèles utiliser et lesquels éviter, et ainsi de suite.
Ce flot de récits de microservices laisse très peu de place à une analyse objective des avantages et des inconvénients de « l’architecture des microservices ».
Peut-être, cela vaut-il la peine de partir d’une explication, pourquoi dans la dernière phrase « architecture de microservices » est écrit entre guillemets. La réponse est assez simple, car il n’existe pas d’« architecture de microservices ». Il n’y a pas non plus d’« architecture monolithique ». Pour de nombreuses applications basées sur des microservices, il est possible de les reconditionner en un seul artefact déployable en modifiant simplement la version, les options de conditionnement ou la configuration. L’application « monolithique » résultante aura une architecture identique, mais ne sera plus basée sur des microservices. D’où, les microservices/monolithes ne sont que des options de packaging du point de vue de l’architecture.
Bien sûr, l’utilisation de microservices affecte les décisions architecturales, mais cela ne signifie pas que les microservices sont une architecture. Par exemple, la pile logicielle affecte également les décisions d’architecture, mais personne n’essaie de l’appeler « architecture ».
Curieux constat : il n’est pas toujours possible de faire une transition d’artefacts simples à multiples déployables, ou de « casser le monolithe ». Pas nécessairement parce que le « monolithe » est mal conçu ou mis en œuvre (cela arrive aussi, mais c’est une autre histoire). La raison réelle est que l’architecture interne peut ne pas être basée sur les services. Par exemple, l’architecture hexagonale est difficile ou impossible à refactoriser dans une architecture basée sur les services. Autre cause possible : pour des raisons commerciales, il peut être impossible de diviser les domaines en services. Après tout, les applications sont créées pour résoudre des problèmes commerciaux, et non l’inverse.
En fait, si vous jetez un œil à toutes ces tonnes d’articles consacrés à la transition vers les microservices, vous remarquerez peut-être que le seul choix d’architecture que vous avez est une variante spécifique de l’architecture orientée services avec plusieurs modèles spécifiques aux microservices appliqués. En d’autres termes, les microservices limitent le nombre de choix architecturaux possibles.
Il convient de mentionner certains modèles liés aux microservices :
- Services étendus au domaine
- Une seule base de données par service
- Communication entre services via des canaux peu fiables et des protocoles à peine adaptés comme HTTP (il existe d’autres options, mais elles sont même très rarement évoquées, encore moins discutées)
- Les transactions ACID traditionnelles sont remplacées par le modèle Saga
La plupart de ces modèles tentent de résoudre les problèmes qui sont apportés par les microservices et n’existent pas dans les systèmes traditionnels. Et la plupart d’entre eux ont leurs problèmes. En retour, les partisans des microservices promettent de nombreux avantages tels qu’un déploiement séparé, une mise à l’échelle facile, une isolation des pannes et une tolérance aux pannes, un développement indépendant de services, une testabilité améliorée, etc.
Je vais analyser ces avantages un par un, mais cela vaut la peine d’examiner d’abord l’image de haut niveau du système basé sur les microservices.
Microservices et complexité du système
La complexité de chaque système logiciel dépend de deux parties principales : le nombre de composants et le nombre de liens entre composants. L’approche habituelle est de réduire au maximum la complexité car elle a des conséquences lourdes pour le système et l’organisation qui l’utilise.
Ce n’est pas le cas pour les microservices : chaque système basé sur des microservices ressemble à une application traditionnelle à l’envers — toutes les dépendances internes entre les services sont exposées au monde extérieur. En plus de la complexité interne préexistante, cette transition a ajouté quelques sources de complexité supplémentaires (sans ordre particulier) :
- Augmentation du temps de réponse (la réalisation du SLA est plus complexe).
- Chaque appel d’autres services peut échouer.
- Données dispersées entre les services, compliquant l’accès et provoquant souvent des doublons et/ou une récupération/un traitement beaucoup plus complexe
- Toute transaction qui franchit la frontière du service devient désormais beaucoup plus complexe.
- L’infrastructure utilisée pour déployer les services individuels fait désormais partie intégrante du système.
- Chaque service doit être configuré.
Habituellement, lorsque la complexité est augmentée, cela est justifié par les avantages fournis par une complexité accrue. Par exemple, une voiture moderne est bien plus complexe que la Ford Model T. En retour, nous avons obtenu de meilleures performances, confort et sécurité. Les microservices apportent beaucoup de complexité supplémentaire, mais qu’obtenons-nous en retour ?
Déploiement séparé
Le déploiement séparé est une propriété inhérente des microservices — ils ne peuvent tout simplement pas être préparés ensemble en même temps. Tant que tous les services ne sont pas prêts, l’ensemble du système n’est pas fonctionnel. Le redéploiement d’un service rend également l’ensemble du système non fonctionnel, à moins que le service ne soit placé derrière un équilibreur de charge et qu’il y ait plus d’une instance de service en cours d’exécution.
Habituellement, il est annoncé qu’un déploiement séparé permet de mettre à jour les services de manière indépendante. C’est en effet un avantage si une application traditionnellement packagée prend trop de temps à démarrer. Mais sinon, il n’y a aucun avantage sensible dans le déploiement séparé.
Le déploiement séparé a également ses inconvénients :
- L’application des changements qui traversent les frontières des services est beaucoup plus compliquée.
- Les modifications de l’API nécessitent une attention et une gestion particulières.
Mise à l’échelle facile
En théorie, un système basé sur des microservices peut être mis à l’échelle en ajoutant plus d’instances du service nécessaire. En pratique, cela signifie que chaque service, que nous allons faire évoluer, doit être placé derrière l’équilibreur de charge. Cela signifie évidemment plus de configuration et de maintenance de l’infrastructure.
Mais les complications ne se sont pas arrêtées là. Comme mentionné ci-dessus, l’un des modèles de microservices est « Single DB par service ». Si plusieurs instances du service doivent être lancées, trois choix sont possibles :
- Utiliser des bases de données indépendantes par instance
- Utiliser le partitionnement
- Utiliser la même base de données
Le premier choix n’est généralement pas une option car les instances doivent être identiques du point de vue des utilisateurs/services externes. S’ils utilisent des bases de données indépendantes, il n’existe aucun moyen simple d’assurer la cohérence des données.
La deuxième option est plus intéressante. Le partitionnement est une technique bien connue et largement utilisée pour mettre à l’échelle des bases de données. Le problème ici est que toutes les partitions doivent être accessibles pour s’assurer que toutes les données sont disponibles. Cela signifie qu’il n’existe aucun moyen simple de remplacer une seule partition ou de reconfigurer des partitions de manière dynamique. En d’autres termes, bien que cette option soit possible, elle ne permet pas la mise à l’échelle dynamique comme annoncé.
Enfin, le dernier choix ne fait que déplacer le goulot d’étranglement du service vers la base de données. Malheureusement, cela n’a de sens que dans un nombre restreint de cas. Généralement, un service correctement conçu et implémenté est lié aux E/S (en particulier, les E/S DB), donc la mise à l’échelle en ajoutant de nouvelles instances n’améliorera pas les performances. Ainsi, cette approche n’est sensée que si elle effectue des calculs lourds ou est écrite avec des porcs de ressources populaires comme Spring.
Jetons un coup d’œil à la mise à l’échelle des microservices en général. Il semble que les systèmes basés sur des microservices n’adoptent qu’une seule façon de s’adapter : en lançant plus d’instances, avec toutes les dépenses d’exploitation pertinentes. Il existe de nombreuses autres options, qui ne sont pas disponibles pour les microservices, par exemple, la mise à l’échelle en déplaçant la charge vers d’autres conteneurs qui ne sont pas si lourdement chargés. Aucun d’entre eux n’est disponible pour les microservices. En conséquence, les options de mise à l’échelle sont non seulement limitées, mais même les ressources disponibles sont utilisées de manière inefficace.
Isolation des pannes et tolérance aux pannes
En théorie, les microservices permettent d’isoler les pannes : lorsqu’un service tombe en panne, les autres continuent de fonctionner.
En réalité, un système partiellement fonctionnel n’est pas toujours ce qui est réellement nécessaire/désiré car il est sujet à la perte ou à la corruption de données. La conception traditionnelle consiste à arrêter l’application lorsqu’elle rencontre une défaillance irrécupérable. Bien que cela puisse rendre le système moins disponible, cela le rend en même temps beaucoup plus résistant à la perte et à la corruption de données. Il convient également de garder à l’esprit que le nombre de scénarios de défaillance possibles est assez limité (manque de mémoire, pas d’espace disque, etc.) et change à peine au fur et à mesure que le système évolue.
Ainsi, pour éviter la perte/la corruption de données, le système basé sur des microservices doit être conçu en tenant compte des scénarios de défaillance possibles. Tous. Les microservices sont un système distribué, donc, outre les défaillances traditionnelles bien connues, il existe des défaillances de communication qui doivent être prises en compte. L’ajout d’un nouveau microservice augmente le nombre de scénarios de défaillance possibles. Le pire est que toute la gestion des échecs se produit au niveau de la logique métier, c’est-à-dire que le développeur doit garder à l’esprit les échecs possibles lors de l’écriture de la logique métier. Cela viole clairement le principe de séparation des préoccupations, et ce problème est inhérent aux microservices.
Une autre approche possible consiste à déployer des services dans un maillage de services et à lancer quelques instances du service. Cela résoudra, ou, au moins, atténuera, bon nombre des problèmes mentionnés ci-dessus. Malheureusement, cette approche est coûteuse en termes d’efforts et de dépenses opérationnelles. Pire encore, cette approche ne fournit aucune garantie de tolérance aux pannes. Après tout, si une charge/demande spécifique a provoqué l’échec d’une instance, il est fort probable que cela entraînera également l’échec d’autres instances.
Autre question importante : doit-on considérer un système capable de survivre à la défaillance d’une pièce (service) tolérant aux pannes ? Selon la définition commune, pour être considéré comme tolérant aux pannes, le système doit être capable de continuer à fonctionner après une panne, peut-être avec un débit réduit et/ou un temps de réponse accru. Selon cette définition, les systèmes basés sur des microservices n’ont pas de tolérance aux pannes inhérente – la défaillance d’un service rend le système incapable de gérer les demandes.
Développement de services indépendants
Il est à noter que cette propriété n’est pas technique. Elle est purement organisationnelle et peut donc s’appliquer à tout type de système. Néanmoins, les microservices devraient être crédités pour une acceptation beaucoup plus large de la conception dirigée par le domaine. De plus, les microservices ne laissent aucune place aux « raccourcis », ce qui est généralement possible dans la conception traditionnelle. Dans l’ensemble, cela rend la conception de l’ensemble du système beaucoup plus propre.
Mais, encore une fois, cette propriété n’est pas unique aux microservices. Il est encore possible d’utiliser des approches similaires pour la conception et la mise en œuvre d’autres types de systèmes.
Dépendance envers l’infrastructure
Comme mentionné ci-dessus, l’infrastructure fait partie intégrante de tout système basé sur des microservices. Ce fait a plusieurs implications :
- Complexité des infrastructures. Chaque service est unique et a ses dépendances et sa configuration.
- Il n’y a aucun moyen de lancer le système sans infrastructure.
- Le système est généralement lié à un seul fournisseur de cloud. Le changement de fournisseur est possible mais coûteux.
- Les dépenses d’exploitation sont nettement plus élevées.
- Tenter d’adopter des microservices sans une équipe d’exploitation qualifiée est presque inévitablement voué à l’échec dès le début.
À un moment donné, la complexité des infrastructures augmente tellement qu’il est nécessaire d’en introduire encore plus…