Bonjour Habr! je présente à votre attention traduction de l'auteur de l'article .
À l’heure où le monde informatique s’oriente progressivement vers des microservices et des outils comme Kubernetes, un seul problème devient de plus en plus visible. Ce problème - versions de microservices. Pourtant, la communauté informatique estime que la situation actuelle est bien meilleure que celle génération précédente de technologies. Cependant, la gestion des versions des microservices est un problème très complexe. Une preuve en est des articles comme .
Si vous ne comprenez toujours pas le problème en lisant ce texte, laissez-moi vous expliquer. Disons que votre produit se compose de 10 microservices. Supposons maintenant qu'une nouvelle version soit publiée pour chacun de ces microservices. Une seule version - j'espère que nous pouvons tous convenir qu'il s'agit d'un fait très trivial et insignifiant. Mais maintenant, jetons un autre regard sur notre produit. Avec une seule nouvelle version de chaque composant, nous disposons désormais de 1 ^ 1, soit 2 10 permutations de la façon dont notre produit peut être composé.
S’il y a encore un malentendu, permettez-moi de détailler les calculs. Nous avons donc 10 microservices, chacun recevant une mise à jour. Autrement dit, nous obtenons 2 versions possibles pour chaque microservice (ancienne ou nouvelle). Désormais, pour chacun des composants du produit, nous pouvons utiliser l'une ou l'autre de ces deux versions. Mathématiquement, c'est comme si nous avions un nombre binaire de 10 chiffres. Par exemple, disons que 1 est la nouvelle version et 0 est l'ancienne version - alors une permutation possible peut être notée 1001000000 - où les 1er et 4ème composants sont mis à jour, et tous les autres ne le sont pas. D'après les mathématiques, nous savons qu'un nombre binaire à 10 chiffres peut avoir 2 ^ 10 ou 1024 XNUMX valeurs. Autrement dit, nous avons confirmé l’ampleur du nombre auquel nous avons affaire.
Poursuivons notre raisonnement plus loin : que se passera-t-il si nous avons 100 microservices et que chacun a 10 versions possibles ? La situation dans son ensemble devient plutôt désagréable – nous avons maintenant 10 ^ 100 permutations – ce qui est un nombre énorme. Cependant, je préfère qualifier cette situation de cette façon, car désormais nous ne nous cachons plus derrière des mots comme « kubernetes », mais plutôt face au problème tel qu'il est.
Pourquoi suis-je si fasciné par ce problème ? En partie parce que, ayant déjà travaillé dans le monde de la PNL et de l’IA, nous avons beaucoup discuté du problème de l’explosion combinatoire il y a environ 5 à 6 ans. Seulement, au lieu de versions, nous avions des mots individuels, et au lieu de produits, nous avions des phrases et des paragraphes. Et même si les problèmes de la PNL et de l’IA restent largement irrésolus, force est de reconnaître que des progrès significatifs ont été réalisés ces dernières années. (à mon avis, des progrès pourraient être réalisésоIl vaudrait mieux que les gens de l'industrie accordent un peu moins d'attention à l'apprentissage automatique et un peu plus aux autres techniques - mais c'est déjà hors sujet).
Revenons au monde du DevOps et des microservices. Nous sommes confrontés à un énorme problème, se faisant passer pour un éléphant dans la Kunstkamera - car ce que j'entends souvent c'est « prenez simplement Kubernetes et le casque, et tout ira bien ! » Mais non, tout n’ira 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 en PNL, nous devons d’abord aborder ce problème en limitant la portée de la recherche – dans ce cas, en éliminant les permutations obsolètes.
Une des choses qui pourraient aider est quelque chose que j'ai écrit l'année dernière . Il est également important de noter qu’un processus CI/CD bien conçu contribue grandement à réduire les variations. Cependant, l’état actuel des choses avec CI/CD n’est pas suffisant pour résoudre le problème des permutations sans outils supplémentaires pour les composants de comptabilité et de suivi.
Ce dont nous avons besoin, c'est d'un système d'expérimentation au stade de l'intégration, où nous pouvons déterminer le facteur de risque pour chaque composant, et également d'un processus automatisé de mise à jour des différents 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érimentations 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'étiquetage des données en machine learning).
- Chaque composant (projet) reçoit son propre système CI - ce processus est désormais bien développé et le problème de la création d'un système CI pour un seul composant a été largement résolu
- Le « système d'intégration intelligent » collecte les résultats de divers systèmes CI et assemble les projets de composants dans le produit final, exécute des tests et calcule enfin le chemin le plus court pour obtenir la fonctionnalité de produit souhaitée en fonction des composants existants et des facteurs de risque. Si une mise à jour n'est pas possible, ce système informe les développeurs des composants existants et de ceux qui sont à l'origine de l'erreur. Une fois de plus, le système de tests revêt ici une importance cruciale, puisque le système d'intégration utilise les tests comme critère d'évaluation.
- Système CD, qui reçoit ensuite les données du Smart Integration System et effectue directement la mise à jour. Cette étape termine le cycle.
Pour résumer, pour moi, l’un des plus gros problèmes actuellement est l’absence d’un tel « système d’intégration intelligent » qui relierait les différents composants dans un produit et permettrait ainsi de suivre la façon dont le produit dans son ensemble est assemblé. Je serai intéressé par l'avis de la communauté à ce sujet (spoiler - je travaille actuellement sur un projet , qui peut devenir un tel système d'intégration intelligent).
Une dernière chose que je tiens à mentionner est que, pour moi, un monolithe n’est acceptable pour aucun projet, même de taille moyenne. Pour moi, les tentatives visant à accélérer le temps de mise en œuvre et la qualité du développement en revenant à un monolithe suscitent un grand scepticisme. Premièrement, un monolithe a un problème similaire de gestion des composants - parmi les différentes bibliothèques qui le composent, cependant, tout cela n'est pas si visible et se manifeste principalement dans le temps passé par les développeurs. La conséquence du problème du monolithe est la quasi-impossibilité d’apporter des modifications au code – et une vitesse de développement extrêmement lente.
Les microservices améliorent la situation, mais l'architecture des microservices est alors confrontée au problème de l'explosion combinatoire au stade de l'intégration. Oui, de manière générale, nous avons déplacé la même problématique 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 taille du lot). Cependant, le passage du monolithe aux microservices n'a pas encore suffisamment amélioré le processus - l'explosion combinatoire des versions de microservices est un énorme problème, et nous avons beaucoup de potentiel pour améliorer la situation à mesure que nous la résolvons.
Source: habr.com