Hallo, Habr! Ich präsentiere Ihnen die autorisierte Übersetzung des Artikels .
In einer Zeit, in der die IT-Welt allmählich auf Mikrodienste und Werkzeuge wie Kubernetes umschaltet, wird ein Problem zunehmend sichtbar. Dieses Problem ist von Versionen der Mikrodienste. Die IT-Community glaubt jedoch, dass die heutige Situation deutlich besser ist als die der vorherigen Generation von Technologien. Dennoch ist das Versionsmanagement von Mikrodiensten ein sehr komplexes Problem. Ein Beweis dafür sind Artikel wie .
Wenn Sie diesen Text lesen und das Problem noch nicht verstehen, lassen Sie mich erklären. Angenommen, Ihr Produkt besteht aus 10 Mikrodiensten. Nehmen wir nun an, dass für jeden dieser Mikrodienste eine neue Version herauskommt. Nur eine Version – ich hoffe, wir können uns alle darauf einigen, dass dies ein ziemlich triviales und unbedeutendes Faktum ist. Schauen wir jedoch unser Produkt noch einmal an. Mit nur einer neuen Version jedes einzelnen Bauteils haben wir jetzt 2^10 – oder 1024 Permutationen, wie wir unser Produkt zusammenstellen können.
Falls noch Unklarheiten bestehen, lassen Sie mich die Mathematik aufschlüsseln. Wir haben also 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). Für jedes Produktkomponente können wir nun eine dieser beiden Versionen wählen. Mathematisch gesehen ist das dasselbe, als ob wir eine binäre Zahl mit 10 Stellen hätten. Zum Beispiel, sagen wir, dass 1 die neue Version und 0 die alte Version ist – dann könnte eine mögliche Permutation als 1001000000 dargestellt werden, wobei der 1. und der 4. Komponente aktualisiert sind, während alle anderen es nicht sind. Aus der Mathematik wissen wir, dass eine binäre Zahl aus 10 Stellen 2^10 oder 1024 Werte haben kann. Das heißt, wir haben das Ausmaß der Zahl, mit der wir es zu tun haben, bestätigt.
Lassen Sie uns weiter darüber nachdenken – was passiert, wenn wir 100 Mikrodienste haben und jeder 10 mögliche Versionen? Die Situation wird äußerst unangenehm – jetzt haben wir 10^100 Permutationen – und das ist eine gewaltige Zahl. Dennoch ziehe ich es vor, diese Situation so zu benennen, denn nun verstecken wir uns nicht hinter Worten wie „Kubernetes“, sondern begegnen dem Problem, wie es ist.
Warum fasziniert mich dieses Problem so sehr? Teilweise, weil wir vor etwa 5-6 Jahren in der Welt von NLP und KI viel über das Problem der kombinatorischen Explosion diskutiert haben. Nur dass wir anstelle von Versionen individuelle Wörter hatten und anstelle von Produkten Sätze und Absätze. Und obwohl die Probleme von NLP und KI nach wie vor weitgehend ungelöst bleiben, muss man zugeben, dass in den letzten Jahren erhebliche Fortschritte erzielt wurden. (meiner Meinung nach könnte der Fortschritt größer sein,größtenwenn die Menschen in der Branche etwas weniger Aufmerksamkeit auf maschinelles Lernen und etwas mehr auf andere Techniken richten würden — aber das ist ein anderes Thema).
Kehren wir zur Welt von DevOps und Microservices zurück. Wir stehen vor einem riesigen Problem, das sich wie ein Elefant im Raum tarnt — denn was ich oft höre, ist: „Nimm einfach Kubernetes und Helm, dann wird alles gut!“. Aber nein, es wird nicht gut, wenn man alles so lässt, wie es ist. Darüber hinaus scheint eine analytische Lösung dieses Problems aufgrund der Komplexität nicht akzeptabel. Wie im NLP sollten wir uns diesem Problem zunächst durch eine Eingrenzung des Suchbereichs nähern — in diesem Fall durch den Ausschluss veralteter Permutationen.
Eine der Dinge, die helfen können, ist, dass ich letztes Jahr geschrieben habe . Es ist auch wichtig zu beachten, dass ein gut durchdachter CI/CD-Prozess sehr dafür hilfreich ist, Variationen zu reduzieren. Allerdings ist die gegenwärtige Situation mit CI/CD nicht gut genug, um das Problem der Permutationen ohne zusätzliche Tools zur Verwaltung und Verfolgung der Komponenten zu lösen.
Was wir brauchen, ist ein Experimentiersystem in der Integrationsphase, in dem wir das Risikofaktor jedes Komponente bestimmen könnten, sowie einen automatisierten Prozess zur Aktualisierung verschiedener Komponenten und Tests ohne Eingreifen des Betreibers — um zu sehen, was funktioniert und was nicht.
Ein solches Experimentiersystem könnte wie folgt aussehen:
- Entwickler schreiben Tests (das ist eine kritische Phase — denn sonst haben wir keinen Bewertungsmaßstab — es ist wie die Datenmarkierung im maschinellen Lernen).
- Jede Komponente (Projekt) erhält ihr eigenes CI-System — dieser Prozess ist heute gut etabliert, und die Frage des Aufbaus eines CI-Systems für eine einzelne Komponente ist weitgehend gelöst.
- Das "smarte Integrationssystem" sammelt die Ergebnisse verschiedener CI-Systeme und fasst die Projektkomponenten zu einem Endprodukt zusammen, führt Tests durch und berechnet schließlich den direktesten Weg, um die erforderliche Funktionalität des Produkts basierend auf verfügbaren Komponenten und Risikofaktoren zu erzielen. Wenn ein Upgrade nicht möglich ist, informiert dieses System die Entwickler über vorhandene Komponenten und den spezifischen Fehler. Ich betone noch einmal, dass das Testsystem hier von entscheidender Bedeutung ist — da das Integrationssystem Tests als Bewertungsmaßstab verwendet.
- Das CD-System, das dann die Daten aus dem "smart Integration System" erhält und direkt das Update durchführt. Diese Phase schließt den Zyklus ab.
Zusammenfassend lässt sich sagen, dass eines meiner größten Probleme derzeit das Fehlen eines „intelligenten Integrationssystems“ ist, das verschiedene Komponenten innerhalb des Produkts verbindet und somit nachvollziehbar macht, wie das Produkt insgesamt zusammengesetzt ist. Mich interessieren die Gedanken der Community zu diesem Thema (Spoiler — ich arbeite gerade an einem Projekt , das ein solches intelligentes Integrationssystem werden könnte).
Eine letzte Sache, die ich erwähnen möchte — für mich ist ein Monolith für jedes Projekt mittlerer Größe nicht akzeptabel. Ich bin äußerst skeptisch gegenüber den Versuchen, die Entwicklungszeit und -qualität durch die Rückkehr zu einem Monolithen zu beschleunigen. 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 hauptsächlich in der Zeit, die die Entwickler aufwenden. Die Folge des Monolith-Problems ist die tatsächliche Unmöglichkeit, Änderungen am Code vorzunehmen — und die extrem langsame Geschwindigkeit der Entwicklung.
Mikrodienste verbessern die Situation, jedoch steht die mikrodienstliche Architektur dann vor dem Problem der kombinatorischen Explosion in der Integrationsphase. Ja, im Großen und Ganzen haben wir dasselbe Problem verschoben – von der Entwicklungsphase in die Integrationsphase. Dennoch führt meiner Meinung nach der Ansatz der Mikrodienste zu besseren Ergebnissen, und die Teams erreichen schneller Resultate (wahrscheinlich vor allem aufgrund der verringerten Größe der Entwicklungseinheit – oder Batch-Größe). Der Übergang vom Monolithen zu Mikrodiensten hat jedoch bisher keinen ausreichenden Prozessverbesserung gebracht – die kombinatorische Explosion der Versionen von Mikrodiensten ist ein riesiges Problem, und wir haben ein großes Verbesserungspotenzial, während wir dieses Problem lösen.
Quelle: habr.com
