Mikroservices – kombinatorische Explosion der Versionen

Hallo, Habr! Ich präsentiere Ihnen die autorisierte Übersetzung des Artikels Mikrodienste – Kombinatorische Explosion von Versionen.

In einer Zeit, in der die IT-Welt allmählich auf Mikrodienste und Werkzeuge wie Kubernetes umschaltet, wird ein Problem immer auffälliger. Dieses Problem ist die kombinatorische Explosion von Versionen der Mikrodienste. Dennoch glaubt die IT-Community, dass die heutige Situation erheblich besser ist als die "Dependency hell" der vorherigen Generation von Technologien. Trotzdem ist das Versionieren von Mikrodiensten ein sehr komplexes Problem. Ein Beleg dafür sind Artikel wie "Gib mir meinen Monolithen zurück".

Wenn Sie beim Lesen dieses Textes die Problematik noch nicht verstehen, lassen Sie es mich erklären. Angenommen, Ihr Produkt besteht aus 10 Mikrodiensten. Nehmen wir nun an, dass für jeden dieser Mikrodienste eine neue Version veröffentlicht wird. Nur eine Version – ich hoffe, wir können uns alle darauf einigen, dass dies ein äußerst triviales und wenig signifikantes Faktum ist. Schauen wir uns nun jedoch unser Produkt erneut an. Mit nur einer neuen Version jedes einzelnen Komponents haben wir jetzt 2^10 – also 1024 Permutationen, wie unser Produkt zusammengesetzt werden kann.

Falls es noch Unklarheiten gibt, lassen Sie mich die Mathematik erläutern. Also, wir haben 10 Mikrodienste, jeder erhält ein Update. Das bedeutet, dass wir 2 mögliche Versionen für jeden Mikrodienst haben (entweder die alte oder die neue). Nun können wir für jedes der Produktkomponenten eine dieser beiden Versionen verwenden. Mathematisch betrachtet ist das dasselbe, als hätten wir eine binäre Zahl mit 10 Ziffern. Zum Beispiel, nehmen wir an, dass 1 die neue Version und 0 die alte Version ist – dann könnte eine mögliche Permutation als 1001000000 dargestellt werden – wobei die 1. und 4. Komponente aktualisiert sind, während alle anderen es nicht sind. Aus der Mathematik wissen wir, dass eine binäre Zahl mit 10 Ziffern 2^10 oder 1024 Werte haben kann. Das heißt, wir haben das Ausmaß der Anzahl, mit der wir es zu tun haben, bestätigt.

Lassen Sie uns die Überlegungen weiterführen – was passiert, wenn wir 100 Mikrodienste haben und jeder 10 mögliche Versionen? Die gesamte Situation wird äußerst unangenehm – nun haben wir 10^100 Permutationen – und das ist eine riesige Zahl. Trotzdem ziehe ich es vor, diese Situation genau so zu bezeichnen, denn jetzt verstecken wir uns nicht hinter Worten wie "Kubernetes", sondern begegnen dem Problem, wie es ist.

Warum mich dieses Problem so fasziniert? Teilweise, weil wir vor etwa 5-6 Jahren viel über das Problem der kombinatorischen Explosion in der Welt der NLP und KI diskutiert haben. Anstelle von Versionen hatten wir einzelne Wörter, und anstelle von Produkten hatten wir Sätze und Absätze. Und obwohl die Probleme in der NLP und KI nach wie vor zu einem großen Teil ungelöst bleiben, muss man anerkennen, dass in den letzten Jahren erhebliche Fortschritte erzielt wurden. (meiner Meinung nach könnte der Fortschritt größer sein,owenn die Leute in der Branche etwas weniger Aufmerksamkeit auf maschinelles Lernen und etwas mehr auf andere Techniken legen würden — aber das ist ein anderes Thema).

Lass uns zur Welt von DevOps und Microservices zurückkehren. Vor uns steht ein gewaltiges Problem, das sich wie ein Elefant im Raum versteckt — denn was ich oft höre, ist: „Nimm einfach Kubernetes und Helm, und alles wird gut!“ Aber nein, alles wird nicht gut, wenn man alles so belässt, wie es ist. Darüber hinaus scheint eine analytische Lösung dieses Problems aufgrund der Komplexität nicht akzeptabel zu sein. Wie in der NLP sollten wir uns diesem Problem zuerst durch Eingrenzung des Suchbereichs nähern — in diesem Fall durch den Ausschluss veralteter Permutationen.

Eine der Dinge, die helfen können — ich habe letztes Jahr darüber geschrieben, wie wichtig es ist, eine minimale Streuung zwischen den Versionen zu halten, die den Kunden bereitgestellt werden.Es ist auch wichtig zu beachten, dass ein gut ausgearbeiteter CI/CD-Prozess sehr dazu beiträgt, die Variationen zu reduzieren. Allerdings ist der aktuelle Stand der CI/CD nicht gut genug, um das Problem der Permutationen ohne zusätzliche Instrumente zur Dokumentation und Verfolgung 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 für die Aktualisierung verschiedener Komponenten und das Testen ohne Eingreifen eines Operators haben können — um zu sehen, was funktioniert und was nicht.

Ein solches Experimentiersystem könnte folgendermaßen aussehen:

1. Entwickler schreiben Tests (dies ist ein kritischer Schritt — denn sonst haben wir kein Bewertungskriterium — das ist wie die Datenmarkierung im maschinellen Lernen).
2. Jede Komponente (Projekt) erhält ihr eigenes CI-System — dieser Prozess ist heute gut etabliert, und die Frage, ein CI-System für eine einzelne Komponente zu erstellen, ist weitgehend gelöst.
3. Das „Intelligente Integrationssystem“ sammelt die Ergebnisse verschiedener CI-Systeme und fasst Projektkomponenten zu einem Endprodukt zusammen, führt Tests durch und berechnet schließlich den kürzesten Weg, um die benötigte Funktionalität des Produkts basierend auf den vorhandenen Komponenten und Risikofaktoren zu erhalten. Wenn ein Update nicht möglich ist, benachrichtigt dieses System die Entwickler über die vorhandenen Komponenten und bei welchem von diesen der Fehler auftritt. Ich möchte noch einmal betonen, dass das Testsystem hier von kritischer Bedeutung ist – da das Integrationssystem Tests als Bewertungskriterium verwendet.
4. Das CD-System, das dann die Daten aus dem „Intelligenten Integrationssystem“ erhält und das eigentliche Update durchführt. Diese Phase schließt den Zyklus ab.

Zusammenfassend ist eines der größten Probleme für mich derzeit das Fehlen eines solchen „Intelligenten Integrationssystems“, das verschiedene Komponenten im Produkt verbindet und es so ermöglicht, nachzuvollziehen, wie das Produkt insgesamt zusammengesetzt ist. Ich wäre an den Gedanken der Community dazu interessiert (Spoiler – ich arbeite gerade an einem Projekt Reliza, das ein solches intelligentes Integrationssystem werden könnte).

Eine letzte Sache, die ich erwähnen möchte – für mich ist ein Monolith nicht akzeptabel für jedes Projekt von wenigstens mittlerer Größe. Ich stehe den Versuchen, die Implementierungszeit und die Qualität der Entwicklung durch eine Rückkehr zum Monolithen zu beschleunigen, sehr skeptisch gegenüber. Erstens hat der Monolith ein ähnliches Problem bei der Verwaltung von Komponenten – unter den verschiedenen Bibliotheken, aus denen er besteht, ist dies jedoch nicht so offensichtlich und zeigt sich in erster Linie in der Zeit, die die Entwickler aufwenden. Eine Folge des Monolith-Problems ist die faktische Unmöglichkeit, Änderungen am Code vorzunehmen – und die extrem langsame Entwicklungsgeschwindigkeit.

Mikroservices verbessern die Situation, jedoch sieht sich die mikroservicebasierte Architektur dann dem Problem der kombinatorischen Explosion in der Integrationsphase gegenüber. Ja, im Großen und Ganzen haben wir das gleiche Problem verschoben – von der Entwicklungsphase in die Integrationsphase. Meiner Meinung nach führt der Ansatz der Mikroservices jedoch zu besseren Ergebnissen, und die Teams erreichen schneller Ergebnisse (wahrscheinlich hauptsächlich wegen der Verringerung der Größe der Entwicklungseinheit – oder Batch-Größe). Allerdings hat der Übergang von Monolithen zu Mikrodiensten bisher keine ausreichende Verbesserung des Prozesses gebracht — die kombinatorische Explosion der Versionen von Mikrodiensten ist ein großes Problem, und wir haben großes Verbesserungspotenzial, während wir diese Situation angehen.

Quelle: habr.com