Microservices – eine kombinatorische Explosion von Versionen

Hallo, Habr! Ich präsentiere Ihnen Ihre Aufmerksamkeit Autorenübersetzung des Artikels Microservices – Kombinatorische Explosion von Versionen.

In einer Zeit, in der sich die IT-Welt allmählich in Richtung Microservices und Tools wie Kubernetes bewegt, macht sich nur ein Problem immer deutlicher bemerkbar. Dieses Problem - kombinatorische Explosion Microservice-Versionen. Dennoch glaubt die IT-Community, dass die aktuelle Situation viel besser ist „Abhängigkeitshölle“ vorherige Generation von Technologien. Allerdings ist die Versionierung von Microservices ein sehr komplexes Problem. Ein Beweis dafür können Artikel sein wie „Gib mir meinen Monolithen zurück“.

Wenn Sie das Problem beim Lesen dieses Textes immer noch nicht verstehen, lassen Sie es mich erklären. Nehmen wir an, Ihr Produkt besteht aus 10 Microservices. Nehmen wir nun an, dass für jeden dieser Microservices eine neue Version veröffentlicht wird. Nur eine Version – ich hoffe, wir sind uns alle einig, dass dies eine sehr triviale und unbedeutende Tatsache ist. Schauen wir uns nun aber noch einmal unser Produkt an. Mit nur einer neuen Version jeder Komponente haben wir jetzt 1^1 – oder 2 Permutationen, wie unser Produkt zusammengesetzt werden kann.

Wenn es immer noch ein Missverständnis gibt, lassen Sie mich die Mathematik aufschlüsseln. Wir haben also 10 Microservices, von denen jeder ein Update erhält. Das heißt, wir erhalten für jeden Microservice zwei mögliche Versionen (entweder alt oder neu). Nun können wir für jede der Produktkomponenten eine dieser beiden Versionen verwenden. Mathematisch gesehen ist es dasselbe, als ob wir eine Binärzahl mit 2 Ziffern hätten. Nehmen wir zum Beispiel an, dass 10 die neue Version und 1 die alte Version ist – dann kann eine mögliche Permutation als 0 bezeichnet werden – wobei die 1001000000. und 1. Komponente aktualisiert werden und alle anderen nicht. Aus der Mathematik wissen wir, dass eine 4-stellige Binärzahl 10^2 oder 10 Werte haben kann. Das heißt, wir haben die Größenordnung der Zahl, mit der wir es zu tun haben, bestätigt.

Lassen Sie uns unsere Überlegungen weiterführen: Was passiert, wenn wir 100 Microservices haben und jeder davon 10 mögliche Versionen hat? Die ganze Situation wird ziemlich unangenehm – wir haben jetzt 10^100 Permutationen – was eine riesige Zahl ist. Allerdings bezeichne ich diese Situation lieber so, denn jetzt verstecken wir uns nicht mehr hinter Worten wie „Kubernetes“, sondern stehen dem Problem so gegenüber, wie es ist.

Warum fasziniert mich dieses Problem so sehr? Teilweise, weil wir zuvor in der Welt des NLP und der KI gearbeitet haben und vor etwa fünf bis sechs Jahren viel über das Problem der kombinatorischen Explosion diskutiert haben. Nur hatten wir anstelle von Versionen einzelne Wörter und anstelle von Produkten Sätze und Absätze. Und obwohl die Probleme von NLP und KI noch weitgehend ungelöst sind, muss man zugeben, dass in den letzten Jahren erhebliche Fortschritte erzielt wurden (Meiner Meinung nach könnten Fortschritte erzielt werdenоEs wäre besser, wenn die Leute in der Branche dem maschinellen Lernen etwas weniger Aufmerksamkeit und anderen Techniken etwas mehr Aufmerksamkeit schenken würden – aber das ist schon Off-Topic).

Kehren wir zurück in die Welt von DevOps und Microservices. Wir stehen vor einem riesigen Problem, uns als Elefant in der Kunstkamera auszugeben – denn was ich oft höre ist: „Nehmen Sie einfach Kubernetes und das Ruder, und alles wird gut!“ Aber nein, es wird nicht alles gut, wenn alles so bleibt, wie es ist. Darüber hinaus erscheint eine analytische Lösung dieses Problems aufgrund seiner Komplexität nicht akzeptabel. Wie im NLP sollten wir dieses Problem zunächst angehen, indem wir den Suchbereich einschränken – in diesem Fall durch die Eliminierung veralteter Permutationen.

Eines der Dinge, die helfen könnten, ist etwas, das ich letztes Jahr geschrieben habe über die Notwendigkeit, einen Mindestunterschied zwischen den für Kunden veröffentlichten Versionen einzuhalten. Es ist auch wichtig zu beachten, dass ein gut konzipierter CI/CD-Prozess erheblich dazu beiträgt, Abweichungen zu reduzieren. Allerdings ist der aktuelle Stand der Dinge bei CI/CD nicht gut genug, um das Problem der Permutationen ohne zusätzliche Tools zur Abrechnung und Nachverfolgung von Komponenten zu lösen.

Was wir brauchen, ist ein System zum Experimentieren in der Integrationsphase, in dem wir den Risikofaktor für jede Komponente bestimmen können, und außerdem über einen automatisierten Prozess zum Aktualisieren verschiedener Komponenten und zum Testen ohne Bedienereingriff – um zu sehen, was funktioniert und was nicht.

Ein solches Experimentiersystem könnte wie folgt aussehen:

1. Entwickler schreiben Tests (dies ist eine kritische Phase, da wir sonst kein Bewertungskriterium haben – es ist wie die Kennzeichnung von Daten beim maschinellen Lernen).
2. Jede Komponente (Projekt) erhält ein eigenes CI-System – dieser Prozess ist mittlerweile weit entwickelt und die Frage der Erstellung eines CI-Systems für eine einzelne Komponente ist weitgehend gelöst
3. Das „Smart Integration System“ sammelt die Ergebnisse verschiedener CI-Systeme und fügt Komponentenprojekte zum Endprodukt zusammen, führt Tests durch und berechnet schließlich den kürzesten Weg zum Erreichen der gewünschten Produktfunktionalität auf Basis vorhandener Komponenten und Risikofaktoren. Wenn ein Update nicht möglich ist, benachrichtigt dieses System die Entwickler über die vorhandenen Komponenten und welche davon den Fehler verursachen. Auch hier ist das Testsystem von entscheidender Bedeutung, da das Integrationssystem Tests als Bewertungskriterium verwendet.
4. CD-System, das dann Daten vom Smart Integration System erhält und das Update direkt durchführt. Diese Phase beendet den Zyklus.

Zusammenfassend lässt sich sagen, dass für mich derzeit eines der größten Probleme das Fehlen eines solchen „Smart Integration Systems“ ist, das die verschiedenen Komponenten zu einem Produkt verknüpft und es so ermöglicht, zu verfolgen, wie das Produkt als Ganzes zusammengesetzt wird. Mich interessieren die Gedanken der Community dazu (Spoiler – ich arbeite gerade an einem Projekt Reliza, das zu einem so intelligenten Integrationssystem werden kann).

Eine letzte Sache, die ich erwähnen möchte, ist, dass für mich ein Monolith nicht einmal für ein Projekt mittlerer Größe akzeptabel ist. Versuche, die Implementierungszeit und die Qualität der Entwicklung durch die Rückkehr zu einem Monolithen zu beschleunigen, rufen bei mir große Skepsis hervor. Erstens hat ein Monolith ein ähnliches Problem bei der Verwaltung von Komponenten – bei den verschiedenen Bibliotheken, aus denen er besteht, ist dies jedoch alles nicht so auffällig und äußert sich hauptsächlich im Zeitaufwand der Entwickler. Die Folge des Monolith-Problems ist, dass es praktisch unmöglich ist, Änderungen am Code vorzunehmen – und eine extrem langsame Entwicklungsgeschwindigkeit.

Microservices verbessern die Situation, aber dann steht die Microservice-Architektur in der Integrationsphase vor dem Problem einer kombinatorischen Explosion. Ja, im Allgemeinen haben wir das gleiche Problem von der Entwicklungsphase in die Integrationsphase verschoben. Allerdings führt der Microservices-Ansatz meiner Meinung nach immer noch zu besseren Ergebnissen und Teams kommen schneller zu Ergebnissen (wahrscheinlich hauptsächlich aufgrund der Verkleinerung der Entwicklungseinheit – bzw Losgröße). Allerdings hat der Übergang von Monolith zu Microservices den Prozess noch nicht ausreichend verbessert – die kombinatorische Explosion von Microservice-Versionen ist ein riesiges Problem, und wir haben viel Potenzial, die Situation zu verbessern, während wir es lösen.

Source: habr.com