Bonjour, Habr ! Je vous présente la traduction d'un article .
À une époque où le monde de l'informatique passe progressivement aux microservices et à des outils comme Kubernetes, une seule problématique devient de plus en plus évidente. Cette problématique est des versions des microservices. Cependant, la communauté IT considère que la situation actuelle est beaucoup meilleure que celle de la des générations précédentes de technologies. Néanmoins, la gestion des versions des microservices est un problème très complexe. Un des témoignages à ce sujet peut être trouvé dans des articles comme .
Si vous ne comprenez pas encore le problème en lisant ce texte, laissez-moi vous expliquer. Supposons que votre produit soit composé de 10 microservices. Maintenant, supposons qu'une nouvelle version sorte pour chacun de ces microservices. Juste une version – j'espère que nous pouvons tous convenir que c'est un fait assez trivial et insignifiant. Regardons cependant de nouveau notre produit. Avec une seule nouvelle version de chaque composant, nous avons maintenant 2^10 – ou 1024 permutations de la manière de composer notre produit.
Si la compréhension n'est toujours pas là, laissez-moi décomposer les mathématiques. Donc, nous avons 10 microservices, chacun recevant une mise à jour. Cela signifie que nous obtenons 2 versions possibles pour chaque microservice (soit l'ancienne, soit la nouvelle). Maintenant, pour chacun des composants du produit, nous pouvons utiliser l'une de ces deux versions. Mathématiquement, c'est comme si nous avions un nombre binaire de 10 bits. Par exemple, disons que 1 représente la nouvelle version et 0 l'ancienne version – alors une permutation possible peut être notée comme 1001000000 – où le 1er et le 4ème composants sont mis à jour, tandis que tous les autres ne le sont pas. D'après les mathématiques, nous savons qu'un nombre binaire de 10 bits peut avoir 2^10 ou 1024 valeurs. Cela signifie que nous avons confirmé l'ampleur du nombre avec lequel nous devons traiter.
Poursuivons notre réflexion – que se passerait-il si nous avions 100 microservices et que chacun avait 10 versions possibles ? La situation devient très désagréable – maintenant nous avons 10^100 permutations – ce qui est un nombre gigantesque. Cependant, je préfère désigner cette situation comme elle est, car maintenant nous ne nous cachons pas derrière des mots comme « Kubernetes », mais rencontrons le problème tel qu'il est.
Pourquoi ce problème m fascine-t-il autant ? En partie parce qu'en travaillant auparavant dans le monde du NLP et de l'IA, nous avons beaucoup discuté du problème de l'explosion combinatoire il y a environ 5 à 6 ans. Sauf qu'au lieu de versions, nous avions des mots séparés, et au lieu de produits, nous avions des phrases et des paragraphes. Et bien que les problèmes de NLP et d'IA restent en grande partie non résolus, il faut reconnaître qu'il y a eu des progrès significatifs au cours des dernières années. (À mon avis, le progrès aurait pu être plusdeimportant si les gens dans l'industrie accordaient un peu moins d'attention à l'apprentissage automatique et un peu plus à d'autres techniques — mais c'est déjà un hors-sujet).
Revenons au monde de DevOps et des microservices. Nous sommes confrontés à un énorme problème, qui se masque tel un éléphant dans une vitrine de curiosités — car ce que j'entends souvent est : « prends simplement Kubernetes et Helm, et tout ira bien ! » Mais non, tout ne va pas bien si tout reste tel quel. De plus, une solution analytique à ce problème ne semble pas acceptable en raison de sa complexité. Comme dans le NLP, nous devrions d'abord aborder ce problème en restreignant le domaine de recherche — dans ce cas, en excluant les permutations obsolètes.
Une des choses qui peut aider — j'ai écrit l'année dernière Il est également important de noter qu'un processus CI/CD bien conçu aide beaucoup à réduire les variations. Cependant, la situation actuelle avec CI/CD n'est pas suffisamment bonne pour résoudre le problème des permutations sans un outil supplémentaire de comptabilité et de suivi des composants.
Ce dont nous avons besoin, c'est d'un système d'expérimentation en phase d'intégration, où nous pourrions définir le facteur de risque pour chaque composant, ainsi qu'un processus automatisé de mise à jour des différents composants et de test sans intervention de l'opérateur — pour voir ce qui fonctionne et ce qui ne fonctionne pas.
Un tel système d'expérimentation pourrait ressembler à ceci :
- Les développeurs écrivent des tests (c'est une étape critique — car sinon, nous n'avons pas de critère d'évaluation — c'est comme l'annotation de données dans l'apprentissage automatique).
- Chaque composant (projet) obtient son propre système CI — ce processus est bien développé aujourd'hui, et la question de la création d'un système CI pour un composant unique est en grande partie résolue.
- Le « Système d'Intégration Intelligent » recueille les résultats de divers systèmes CI et assemble les projets-composants en un produit final, lance des tests et enfin calcule le chemin le plus court pour obtenir la fonctionnalité requise du produit en fonction des composants existants et des facteurs de risque. Si la mise à jour est impossible, ce système informe les développeurs des composants disponibles et de celui où l'erreur se produit. Encore une fois, je souligne que le système de tests ici est d'une importance critique — car le système d'intégration utilise les tests comme critère d'évaluation.
- C'est un système CD qui reçoit ensuite les données du « Système d'Intégration Intelligent » et effectue directement la mise à jour. Cette étape conclut le cycle.
Pour résumer, l'un de mes plus grands problèmes actuellement est l'absence d'un tel « Système d'Intégration Intelligent » qui relierait divers composants dans un produit, permettant ainsi de suivre comment le produit est constitué dans son ensemble. Je serais intéressé par les réflexions de la communauté à ce sujet (spoiler — je travaille actuellement sur un projet , qui pourrait devenir un tel système d'intégration intelligent).
Une dernière chose que je veux mentionner — pour moi, le monolithe n'est pas acceptable pour tout projet d'une taille moyenne. Je suis très sceptique quant aux tentatives d'accélérer le temps de mise en œuvre et la qualité du développement en revenant au monolithe. Premièrement, le monolithe rencontre un problème similaire de gestion des composants — parmi les différentes bibliothèques qui le constituent, mais tout cela n'est pas aussi perceptible et se manifeste principalement par le temps que les développeurs passent. Une conséquence du problème du monolithe est l'impossibilité réelle d'apporter des modifications au code — et une vitesse de développement extrêmement lente.
Les microservices améliorent la situation, mais ensuite l'architecture microservices est confrontée au problème de l'explosion combinatoire lors de l'étape d'intégration. Oui, en général, nous avons déplacé le même problème — de l'étape de développement à l'étape d'intégration. Cependant, à mon avis, l'approche des microservices conduit néanmoins à de meilleurs résultats, et les équipes obtiennent des résultats plus rapidement (probablement en grande partie grâce à la réduction de la taille de l'unité de développement — ou taille de lot). Cependant, la transition du monolithe vers les microservices n'a pas encore apporté d'amélioration suffisante au processus — l'explosion combinatoire des versions des microservices est un énorme problème, et nous avons un grand potentiel d'amélioration à mesure que nous résolvons cette situation.
Source : habr.com
