Microservices - explosion combinatoire de versions

Bonjour, Habr! Je vous présente la traduction de l' auteur de l'article Microservices - Explosion combinatoire des versions .

À une époque où le monde informatique évolue progressivement vers des microservices et des outils comme Kubernetes, un seul problème devient plus sensible. Ce problème est une explosion combinatoire des versions de microservices. Néanmoins, la communauté informatique estime que la situation actuelle est bien meilleure que l'enfer de la dépendance de la génération précédente de technologies. Cependant, le contrôle de version des microservices est un problème très complexe. L'une des preuves de cela se trouve dans des articles comme «Rendez-moi mon monolithe» .

Si vous lisez ce texte mais ne comprenez pas le problème, laissez-moi vous expliquer. Supposons que votre produit se compose de 10 microservices. Supposons maintenant que pour chacun de ces microservices 1 nouvelle version soit publiée. Seule version 1 - J'espère que nous pouvons tous convenir qu'il s'agit d'un fait très trivial et insignifiant. Maintenant, jetez un œil à notre produit. Avec une seule nouvelle version de chaque composant, nous avons maintenant 2 ^ 10 - ou 1024 permutations de la façon dont notre produit peut être composé.

S'il y a encore un malentendu, permettez-moi de développer les mathématiques. Nous avons donc 10 microservices, chacun reçoit une mise à jour. Autrement dit, nous obtenons 2 versions possibles pour chaque microservice (ancien ou nouveau). Maintenant, pour chacun des composants du produit, nous pouvons utiliser l'une ou l'autre de ces deux versions. Mathématiquement, c'est la même chose que si nous avions un nombre binaire de 10 caractères. Par exemple, disons que 1 est la nouvelle version et 0 est l'ancienne version - alors une permutation possible peut être désignée comme 1001000000 - où les 1er et 4e composants sont mis à jour, mais tous les autres ne le sont pas. D'après les mathématiques, nous savons qu'un nombre binaire de 10 caractères peut avoir 2 ^ 10 ou 1024 valeurs. Autrement dit, nous avons confirmé l'ampleur du nombre avec lequel il traite.

Nous poursuivons la discussion - et que se passe-t-il si nous avons 100 microservices et chacun a 10 versions possibles? Toute la situation devient très désagréable - nous avons maintenant 10 ^ 100 permutations - et c'est un nombre énorme. Néanmoins, je préfère décrire cette situation comme ça, parce que maintenant nous ne nous cachons pas derrière des mots comme "kubernetes", mais nous rencontrons le problème tel qu'il est.

Pourquoi ce problème est-il si fascinant pour moi? En partie parce que nous travaillions plus tôt dans le monde de la PNL et de l'IA, nous avons discuté de nombreux problèmes d'explosion combinatoire il y a environ 5-6 ans. Seulement au lieu des versions, nous avions des mots séparés, et au lieu des produits, nous avions des phrases et des paragraphes. Bien que les problèmes de la PNL et de l'IA restent en grande partie non résolus, nous devons admettre que des progrès significatifs ont été accomplis au cours des dernières années.(à mon avis, les progrès pourraient être utilisés pour juger si les gens de l'industrie accordaient un peu moins d'attention à l'apprentissage automatique et aux autres techniques - mais cela est hors sujet).

Je reviendrai dans le monde du DevOps et des microservices. Nous sommes confrontés à un énorme problème, déguisé en éléphant dans le Kunstkamera - parce que ce que j'entends souvent, c'est "prenez simplement des kubernetes et un casque, et tout ira bien!" Mais non, tout ne se passera pas bien si tout est laissé tel quel. De plus, une solution analytique à ce problème ne semble pas acceptable au vu de la complexité. Comme dans la PNL, nous devons d'abord aborder ce problème en rétrécissant la portée de la recherche - dans ce cas, en éliminant les permutations obsolètes.

L'une des choses qui peuvent aider - j'ai écrit l'année dernièresur la nécessité de maintenir un écart minimum entre les versions prévues pour les clients . Il est également important de noter qu'un processus CI / CD bien développé est très utile pour réduire les variations. Cependant, la situation actuelle avec CI / CD n'est pas assez bonne pour résoudre le problème de permutation sans outils supplémentaires pour la comptabilité et le suivi des composants.

Ce dont nous avons besoin, c'est d'un système d'expériences au stade de l'intégration, où nous pourrions déterminer le facteur de risque pour chaque composant, et également disposer d'un processus automatisé de mise à jour de divers composants et de tests sans intervention de l'opérateur - pour voir ce qui fonctionne et ce qui ne fonctionne pas.

Un tel système d'expériences pourrait ressembler à ceci:

1. ( — — ).
2. () CI — , CI
3. « » CI - , . , . , — .
4. CD , « » . .

En résumé, pour moi, l'un des plus gros problèmes à l'heure actuelle est l'absence d'un tel «système d'intégration intelligent» qui relierait les différents composants au produit et vous permettrait ainsi de suivre la composition du produit dans son ensemble. Je serai intéressé par les réflexions de la communauté à ce sujet (spoiler - je travaille actuellement sur le projet Reliza , qui pourrait devenir un tel système d’intégration intelligent).

Une dernière chose que je veux mentionner est que pour moi un monolithe n'est pas acceptable pour tout projet de taille au moins moyenne. Pour moi, il y a un grand scepticisme à essayer d'accélérer le temps de mise en œuvre et la qualité du développement en revenant au monolithe. Premièrement, le monolithe a un problème similaire de gestion des composants - parmi les diverses bibliothèques dont il se compose, cependant, tout cela n'est pas si visible et se manifeste principalement dans le temps que les développeurs passent. La conséquence du problème des monolithes est le fait qu'il est impossible d'apporter des modifications au code - et la vitesse de développement est extrêmement lente.

Les microservices améliorent la situation, mais l'architecture des microservices est alors confrontée au problème d'une explosion combinatoire au stade de l'intégration. Oui, en général, nous avons déplacé le même problème - de la phase de développement à la phase d'intégration. Cependant, à mon avis, l'approche des microservices conduit toujours à de meilleurs résultats, et les équipes obtiennent des résultats plus rapidement (probablement principalement en raison de la réduction de la taille de l'unité de développement - ou de la taille du lot ). Cependant, la transition du monolithe aux microservices n'a pas encore fourni une amélioration suffisante du processus - l'explosion combinatoire des versions des microservices est un énorme problème, et nous avons un grand potentiel pour améliorer la situation une fois résolue.