Es scheint, dass der Höhepunkt des Hypes um Mikrodienste hinter uns liegt. Wir lesen nicht mehr mehrmals pro Woche Beiträge wie "Wie ich mein Monolith auf 150 Dienste umgestellt habe". Jetzt höre ich häufiger vernünftige Gedanken: "Ich hasse Monolithen nicht, ich kümmere mich einfach um die Effizienz". Wir haben sogar mehrere Migrationen beobachtet von Mikrodiensten zurück zu Monolithen. Beim Übergang von einer großen Anwendung zu mehreren kleineren Diensten müssen Sie einige neue Probleme lösen. Lassen Sie uns diese so kurz wie möglich auflisten.

Installation: Von grundlegender Chemie zur Quantenmechanik

Die Einrichtung der grundlegenden Datenbank und der Anwendung mit einem Hintergrundprozess war ein ziemlich klarer Prozess. Ich veröffentliche eine Readme auf Github – und oft nach einer Stunde, maximal nach ein paar Stunden, funktioniert alles, und ich beginne ein neues Projekt. Das Hinzufügen und Starten von Code, zumindest für die Anfangsumgebung, geschieht am ersten Tag. Aber wenn wir uns auf Mikrodienste einlassen, schießt die Zeit für den ersten Start in die Höhe. Ja, jetzt haben wir Docker mit Orchestrierung und einen K8-Cluster, aber für einen neuen Programmierer ist all das um ein Vielfaches komplizierter. Für viele Junior-Entwickler ist das eine Belastung, die wirklich eine unnötige Komplexität darstellt.

Das System ist nicht einfach zu verstehen

Lassen Sie uns einen Moment bei unserem Junior bleiben. Bei monolithischen Anwendungen war es einfach, einen Fehler nachzuvollziehen und sofort mit dem Debuggen zu beginnen. Jetzt haben wir einen Dienst, der mit einem anderen Dienst spricht, der etwas in die Warteschlange auf einem Nachrichtenbus stellt, der einen anderen Dienst verarbeitet – und hier taucht ein Fehler auf. Wir müssen all diese Teile zusammenfügen, um letztendlich herauszufinden, dass Dienst A in Version 11 läuft, während Dienst E bereits auf Version 12 wartet. Das unterscheidet sich stark von meinem standardmäßigen konsolidierten Protokoll: Ich muss einen interaktiven Terminal/Debbuger verwenden, um den Prozess Schritt für Schritt durchzugehen. Debugging und Verständnis sind im Grunde komplizierter geworden.

Wenn ich es nicht debuggen kann, testen wir es möglicherweise.

Kontinuierliche Integration und kontinuierliche Entwicklung sind mittlerweile weit verbreitet. Die meisten neuen Anwendungen, die ich sehe, erstellen und führen mit jeder neuen Version automatisch Tests aus und verlangen, dass diese Tests bestehen und überprüft werden, bevor sie registriert werden. Das sind großartige Prozesse, auf die man nicht verzichten kann; sie haben einen großen Wandel für viele Unternehmen bewirkt. Aber jetzt, um den Service wirklich zu überprüfen, muss ich eine vollständige, funktionsfähige Version meiner Anwendung hochfahren. Erinnern Sie sich an den neuen Ingenieur mit dem K8-Cluster aus 150 Diensten? Nun, jetzt werden wir unser CI-System lernen, wie man all diese Systeme zur Überprüfung hochfährt, damit alles wirklich funktioniert. Wahrscheinlich ist das zu viel Aufwand, also testen wir einfach jede einzelne Komponente isoliert: Ich bin mir sicher, unsere Spezifikationen sind gut genug, die APIs sind sauber, und ein Ausfall eines Dienstes ist isoliert und wirkt sich nicht auf andere aus.

Jeder Kompromiss hat einen guten Grund. Stimmt's?

Es gibt viele Gründe, auf Microservices umzusteigen. Ich habe gesehen, dass dies für mehr Flexibilität, für die Skalierung von Teams, für die Leistung und für eine bessere Resilienz gemacht wird. Aber in Wahrheit haben wir Jahrzehnte in die Werkzeuge und Praktiken der Monolith-Entwicklung investiert, die weiterhin gezüchtet werden. Ich arbeite mit Fachleuten in verschiedenen Technologien. Normalerweise sprechen wir über Skalierung, weil sie mit den Grenzen eines einzelnen Postgres-Datenbankknotens konfrontiert sind. Ein großer Teil der Gespräche beschäftigt sich mit DB-Skalierung.

Aber ich bin immer neugierig auf ihre Architektur. An welchem Punkt des Übergangs zu Microservices befinden sie sich? Es ist interessant zu beobachten, wie immer mehr Ingenieure sagen, dass sie mit ihrer monolithischen Anwendung zufrieden sind. Viele werden von Microservices profitieren, und die Vorteile werden die Stolpersteine auf dem Weg zur Migration überwiegen. Aber persönlich, bitte geben Sie mir meine monolithische Anwendung, einen Platz am Strand – und ich bin vollkommen glücklich.

Quelle: habr.com