Microservices - kombinatorische Explosion von Versionen

Hallo Habr! Ich präsentiere Ihnen die Übersetzung des Artikels Microservices - Combinatorial Explosion of Versions des Autors .

In einer Zeit, in der sich die IT-Welt allmählich auf Microservices und Tools wie Kubernetes verlagert, wird nur ein Problem immer deutlicher. Dieses Problem ist eine kombinatorische Explosion von Microservice-Versionen. Dennoch ist die IT-Community der Ansicht, dass die aktuelle Situation viel besser ist als die Abhängigkeitshölle der vorherigen Generation von Technologien. Die Versionskontrolle von Microservices ist jedoch ein sehr komplexes Problem. Einer der Beweise dafür ist in Artikeln wie „Return My Monolith to Me“ zu finden .

Wenn Sie diesen Text lesen und das Problem noch nicht verstehen, lassen Sie es mich erklären. Angenommen, Ihr Produkt besteht aus 10 Microservices. Angenommen, für jeden dieser Microservices wird 1 neue Version veröffentlicht. Nur Version 1 - Ich hoffe, wir können uns alle einig sein, dass dies eine sehr triviale und unbedeutende Tatsache ist. Schauen Sie sich jetzt aber noch einmal unser Produkt an. Mit nur einer neuen Version jeder Komponente haben wir jetzt 2 ^ 10 - oder 1024 Permutationen, wie unser Produkt zusammengesetzt werden kann.

Wenn es immer noch Missverständnisse gibt, lassen Sie mich die Mathematik erweitern. Wir haben also 10 Microservices, von denen jeder ein Update erhält. Das heißt, wir erhalten 2 mögliche Versionen für jeden Microservice (entweder alt oder neu). Jetzt können wir für jede der Produktkomponenten eine dieser beiden Versionen verwenden. Mathematisch ist dies dasselbe, als hätten wir eine Binärzahl von 10 Zeichen. Angenommen, 1 ist die neue Version und 0 ist die alte Version - dann kann eine mögliche Permutation als 1001000000 bezeichnet werden -, wobei die 1. und 4. Komponente aktualisiert werden, der Rest jedoch nicht. Aus der Mathematik wissen wir, dass eine Binärzahl von 10 Zeichen 2 ^ 10 oder 1024 Werte haben kann. Das heißt, wir haben die Skala der Zahl bestätigt, mit der es sich handelt.

Wir setzen die Diskussion fort - und was passiert, wenn wir 100 Microservices und jeweils 10 mögliche Versionen haben? Die ganze Situation wird sehr unangenehm - jetzt haben wir 10 ^ 100 Permutationen - und das ist eine riesige Zahl. Trotzdem beschreibe ich diese Situation lieber einfach so, denn jetzt verstecken wir uns nicht hinter Worten wie „kubernetes“, sondern stoßen auf das Problem, wie es ist.

Warum fasziniert mich dieses Problem so? Zum Teil, weil wir früher in der Welt von NLP und AI gearbeitet haben, haben wir vor etwa 5-6 Jahren viel über das kombinatorische Explosionsproblem diskutiert. Nur anstelle von Versionen hatten wir separate Wörter und anstelle von Produkten hatten wir Sätze und Absätze. Obwohl die Probleme von NLP und KI weitgehend ungelöst bleiben, müssen wir zugeben, dass in den letzten Jahren erhebliche Fortschritte erzielt wurden.(Meiner Ansicht nach könnte der Fortschritt dazu genutzt werden , wenn die Leute in der Branche dem maschinellen Lernen und anderen Techniken etwas weniger Aufmerksamkeit schenken - aber das ist kein Thema).

Ich werde in die Welt von DevOps und Microservices zurückkehren. Wir stehen vor einem großen Problem, das in der Kunstkamera als Elefant getarnt ist - denn ich höre oft: "Nimm einfach Kubernetes und Helm, und alles wird gut!" Aber nein, alles wird nicht gut, wenn alles so bleibt, wie es ist. Darüber hinaus erscheint eine analytische Lösung dieses Problems angesichts der Komplexität nicht akzeptabel. Wie in NLP sollten wir uns diesem Problem zunächst nähern, indem wir den Umfang der Suche einschränken - in diesem Fall indem wir veraltete Permutationen eliminieren.

Eines der Dinge, die helfen können - ich habe letztes Jahr geschriebenüber die Notwendigkeit, einen Mindestabstand zwischen den für Kunden vorgesehenen Versionen einzuhalten . Es ist auch wichtig zu beachten, dass ein gut entwickelter CI / CD-Prozess sehr hilfreich ist, um Variationen zu reduzieren. Der aktuelle Stand der Dinge mit CI / CD ist jedoch nicht gut genug, um das Permutationsproblem ohne zusätzliche Tools zum Aufzeichnen und Verfolgen von Komponenten zu lösen.

Was wir brauchen, ist ein Experimentiersystem in der Integrationsphase, in dem wir den Risikofaktor für jede Komponente bestimmen und einen automatisierten Prozess zum Aktualisieren verschiedener Komponenten und Testen ohne Eingreifen des Bedieners haben können - um zu sehen, was funktioniert und was nicht.

Ein solches Experimentiersystem könnte folgendermaßen aussehen:

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

Zusammenfassend ist eines der größten Probleme für mich das Fehlen eines solchen „intelligenten Integrationssystems“, das die verschiedenen Komponenten mit dem Produkt verbindet und es Ihnen ermöglicht, die Zusammensetzung des gesamten Produkts zu verfolgen. Ich werde mich für die Gedanken der Community interessieren (Spoiler - ich arbeite derzeit am Reliza- Projekt , das zu einem so intelligenten Integrationssystem werden könnte).

Eine letzte Sache, die ich erwähnen möchte, ist, dass ein Monolith für mich für kein Projekt von mindestens mittlerer Größe akzeptabel ist. Ich bin sehr skeptisch, wenn ich versuche, die Implementierungszeit und die Qualität der Entwicklung durch die Rückkehr zum Monolithen zu beschleunigen. Erstens hat der Monolith ein ähnliches Problem bei der Komponentenverwaltung - unter den verschiedenen Bibliotheken, aus denen er besteht, ist dies jedoch nicht so auffällig und manifestiert sich hauptsächlich in der Zeit, die Entwickler verbringen. Die Folge des Monolithproblems ist die Tatsache, dass es unmöglich ist, Änderungen am Code vorzunehmen - und die Entwicklungsgeschwindigkeit ist extrem langsam.

Microservices verbessern die Situation, aber dann steht die Microservice-Architektur vor dem Problem einer kombinatorischen Explosion in der Integrationsphase. Ja, im Allgemeinen haben wir das gleiche Problem verschoben - von der Entwicklungsphase zur Integrationsphase. Meiner Meinung nach führt der Microservice-Ansatz jedoch immer noch zu besseren Ergebnissen, und die Teams erzielen schneller Ergebnisse (wahrscheinlich hauptsächlich aufgrund der Verringerung der Größe der Entwicklungseinheit - oder der Chargengröße ). Der Übergang vom Monolithen zu Mikrodiensten hat den Prozess jedoch noch nicht ausreichend verbessert - die kombinatorische Explosion von Versionen von Mikrodiensten ist ein großes Problem, und wir haben großes Potenzial, die Situation zu verbessern, sobald sie gelöst ist.