On a le sentiment que les microservices sont souvent positionnés comme une «solution miracle» pour remplacer le monolithe. Mais tout le monde n'aime pas cette approche. En fait, il est parfois utilisé de manière incorrecte ou inappropriée. Vous trouverez ci-dessous des exemples de problèmes auxquels j'ai été "chanceux" de faire face lors de l'utilisation de microservices dans différentes entreprises et que je ne souhaite pas répéter à l'avenir.
Évolutivité fantôme
L'évolutivité est un atout majeur de l'approche microservice. Un flux d'utilisateurs infiniment grand et une charge élevée sont considérés comme inévitables. Pour cette raison, beaucoup de temps est consacré à l'optimisation préliminaire et non aux fonctionnalités commerciales utiles. En réalité, des charges élevées ne sont pas toujours présentes.
La première victime de la pré-optimisation est le processus métier linéaire. Il se décompose en de nombreux microservices. Une sorte de réserve pour l'avenir, pour des raisons de partage des responsabilités ou de mise à l'échelle illusoire. En conséquence, il devient plus difficile pour les entreprises de naviguer dans le paysage informatique et de parler le même langage que l'informatique, sans parler des problèmes de navigation dans le code source pour les développeurs eux-mêmes.
Problèmes d'interaction de service
Les services reçus sont dispersés à partir de monorepa sur des référentiels distincts. Les services eux-mêmes sont de plus en plus difficiles à relier. Dans ce cas, la version de l'API de microservice peut commencer à diverger de la version de la même API dans les clients de microservice. Ensuite, le bon vieux JSON est remplacé par Protobuf et HTTP par gRPC afin d'obtenir des performances, un typage et une gestion des versions pratique de l'API.
Malheureusement, des solutions comme gRPC + Protobuf ne garantissent pas qu'il n'y a pas d'erreurs. Les services peuvent tomber de manière séquentielle en raison de la propagation des erreurs et de la non-concordance connue de la paire entrée-sortie de service. La base de code s'agrandit, le débogage des services est beaucoup plus compliqué qu'avec des données en clair, ce qui entraîne un nouveau lot de problèmes.
Ce problème doit être résolu par un processus de test normal. En particulier, les tests d'intégration. Mais les tests d'intégration doivent être écrits et exécutés pour chaque microservice et leur groupe dans le processus métier. C'est une tâche assez compliquée, pour laquelle ils ne veulent généralement pas consacrer de temps supplémentaire. Dans le même temps, le test d'intégration d'un microservice peut être réduit à la forme d'un test unitaire pour un monolithe.
Anciennes restrictions et habitudes
Avec tout cela, les restrictions habituelles pour le monolithe errent dans les microservices. Exemples saisissants: un langage de programmation et une base de données pour tous les microservices. Dans le premier cas, c'est l'ancienne restriction du monolithe, dans le second - l'héritage s'efforçant de devenir le «goulot d'étranglement» de tout le système. En raison du rejet par les développeurs et de la gestion de la possibilité de l'existence d'un système hétérogène construit dans différents langages de programmation, la possibilité de choisir des outils appropriés pour résoudre des problèmes urgents est perdue.
En plus de ce qui précède, les microservices individuels peuvent ne pas avoir de développeurs responsables d'eux. Tout le monde commence à tout supporter, personne n'est responsable de rien. Dans ce cas, personne n'a connaissance du fonctionnement des différents services, à l'exception de la dernière personne qui a changé son code. Il y a une désynchronisation des développeurs, une perte de compréhension de l'essence du travail des microservices par rapport aux tâches résolues dans le cadre du sujet.
Bureaucratie des infrastructures
Les microservices sont plus difficiles à entretenir qu'un monolithe. L'infrastructure qui était autrefois une paire de serveurs devient un petit cloud privé. Les développeurs prennent beaucoup de temps à prendre en charge de telles solutions et créent des problèmes de gestion à l'avenir. Il existe un besoin exagéré de bureaucratie supplémentaire. Des employés individuels sont embauchés, des processus distincts sont créés.
Dans de tels cas, pour maintenir l'intégrité du circuit de microservices, des ensembles de règles pour travailler avec des microservices peuvent être définis. Le pire des cas est le refus même de la possibilité d'exécuter un script ou une migration ponctuelle, sans permettre un accès direct au circuit. L'essentiel est que le script est conçu comme un service à part entière, ajoutant une ligne de plus à la longue liste de microservices.
Futur
Il s'avère qu'un système a beaucoup plus de bruit qu'un signal utile. Partout - de l'infrastructure au code d'un service spécifique. De la compréhension du développeur du schéma d'interaction des services à la gestion de l'entreprise. Les programmeurs deviennent involontairement des maîtres de la résolution d'énigmes.
Bien sûr, le monolithe classique n'est pas meilleur. Il est lent, conserve son état, est difficile à traiter, n'est couvert ni par des tests unitaires ni par des tests d'intégration, etc. Mais nous pouvons faire mieux! Grâce à la mode des microservices, nous avons constaté une augmentation du CI / CD parmi de nombreux autres positifs et avons travaillé sur les tests. Nous pouvons maintenant les appliquer à d'autres approches, pas seulement aux microservices.
La prochaine fois que vous développerez un nouveau système ou recyclerez un ancien, quelle que soit sa taille, pensez-y. Une entreprise a-t-elle besoin d'évolutivité? Est-il nécessaire de faire face à une charge élevée? Êtes-vous vraiment prêt pour les microservices? Ou vaut-il mieux commencer par des architectures plus conservatrices?
Peut-être pas construire une fusée, mais construire un simple scooter, car il suffit de se rendre au bout de la rue?