Wie entsteht beim Wechsel zu Microservices ein Laufzeitproblem?

Der folgende Kommentator schreibt :

Microservices verschieben Ihre organisatorische Dysfunktion von einem Kompilierungsproblem zu einem Laufzeitproblem.

Dieser Kommentator erweitert das Thema und sagt:

Feature nicht Bug. Laufzeitproblem => Produktprobleme => Stärkeres, schnelleres Feedback zu Funktionsstörungen an die Verantwortlichen

Jetzt bekomme ich das mit Microservices :

• Erhöhen Sie möglicherweise die Latenz Ihres Durchsatzes - ein Problem, das sowohl für die Produktion als auch für die Laufzeit von Bedeutung ist.
• Erhöhen Sie die Anzahl der "Netzwerkschnittstellen" in Ihrem Code, an denen möglicherweise Laufzeitfehler beim Parsen auftreten können.
• kann möglicherweise blaugrüne Bereitstellungen durchführen. Diese könnten durch Schnittstelleninkongruenzen aufgehalten werden (siehe Netzwerkschnittstellen). Wenn blaugrüne Bereitstellungen jedoch funktionieren, ist dies eher ein Problem zur Laufzeit.

Meine Frage ist: Was bedeutet es, dass die Umstellung auf Microservices ein Laufzeitproblem verursacht?

Ich habe ein Problem. Nutzen wir Microservices! Jetzt habe ich 13 Probleme verteilt.

Die Aufteilung Ihres Systems in gekapselte, zusammenhängende und entkoppelte Komponenten ist eine gute Idee. Sie können damit verschiedene Probleme separat angehen. In einer monolithischen Bereitstellung ist dies jedoch problemlos möglich (siehe Fowler: Microservice Premium ). Immerhin ist es das, was OOP seit vielen Jahrzehnten lehrt! Wenn Sie Ihre Komponenten in Microservices verwandeln, erhalten Sie keinen architektonischen Vorteil. Sie gewinnen Flexibilität in Bezug auf die Auswahl der Technologie und möglicherweise (aber nicht unbedingt!) Etwas Skalierbarkeit. Aber Sie haben garantiert Kopfschmerzen, die auf (a) die verteilte Natur des Systems und (b) die Kommunikation zwischen Komponenten zurückzuführen sind. Wenn Sie sich für Microservices entscheiden, haben Sie andere Probleme, die so dringlich sind, dass Sie trotz dieser Probleme bereit sind, Microservices zu verwenden.

Wenn Sie keinen Monolithen entwerfen können, der sauber in Komponenten unterteilt ist, können Sie auch kein Microservice-System entwerfen. In einer monolithischen Codebasis wird der Schmerz ziemlich offensichtlich sein. Im Idealfall wird der Code einfach nicht kompiliert, wenn er fürchterlich kaputt ist. Aber mit Microservices kann jeder Dienst separat entwickelt werden, möglicherweise sogar in verschiedenen Sprachen. Probleme im Zusammenspiel von Komponenten werden erst sichtbar, wenn Sie Ihre Komponenten integrieren. Zu diesem Zeitpunkt ist es bereits zu spät, die Gesamtarchitektur zu reparieren.

Die Nr. 1-Fehlerquelle ist das Nichtübereinstimmen der Benutzeroberfläche. Es kann eklatante Fehler wie einen fehlenden Parameter oder subtilere Beispiele geben, z. B. das Vergessen, einen Fehlercode zu überprüfen, oder das Vergessen, eine Vorbedingung zu überprüfen, bevor eine Methode aufgerufen wird. Die statische Eingabe erkennt solche Probleme so früh wie möglich: in Ihrer IDE und im Compiler, bevor der Code jemals ausgeführt wird. Dynamische Systeme haben diesen Luxus nicht. Es wird nicht explodieren, bis dieser fehlerhafte Code ausgeführt wird.

Die Auswirkungen auf Microservices sind erschreckend. Microservices sind von Natur aus dynamisch. Solange Sie nicht zu einer offiziellen Servicebeschreibungssprache wechseln, können Sie die Richtigkeit Ihrer Schnittstellennutzung nicht überprüfen. du musst testen, testen, testen! Tests sind jedoch teuer und in der Regel nicht erschöpfend, sodass die Möglichkeit besteht, dass in der Produktion noch Probleme auftreten. Wann wird sich dieses Problem bemerkbar machen? Nur wenn dieser fehlerhafte Pfad zur Laufzeit in der Produktion genommen wird. Die Vorstellung, dass Produktprobleme zu einer schnelleren Rückmeldung führen würden, istkomisch gefährlich falsch, es sei denn, Sie amüsieren sich über die Möglichkeit eines Datenverlusts.

Der erste Tweet gehörte mir, also werde ich darauf näher eingehen:

Angenommen, Sie haben 100 Entwickler, die an einer monolithischen Anwendung arbeiten. Das sind zu viele Leute, um effektiv miteinander zu kommunizieren. Daher muss das Unternehmen hart daran arbeiten, sie in kleinere Teams aufzuteilen und gute Kommunikationsmuster zwischen ihnen zu schaffen. Wenn die Organisation "dysfunktional" ist, sprechen die Teams wahrscheinlich nicht miteinander, sie sind nicht auf ein größeres Ziel ausgerichtet, sie sind sich nicht einig über Prioritäten usw. - infolgedessen dauert es ewig, bis sie etwas ausliefern. Es ist ein "Kompilierzeitproblem" in dem Sinne, dass die Fehlfunktion offensichtlich ist, bevor die Software erstellt wird. Das Projekt ist wahrscheinlich ein Todesmarsch oder wird niemals ausgeliefert ("compile").

Ich denke, viele Menschen fühlen sich zu Mikrodiensten hingezogen und ziehen zu ihnen um, nicht wegen der inhärenten technischen / architektonischen Vorteile, sondern weil sie die organisatorische Dysfunktion ignorieren können. Anstatt zu versuchen, 100 Entwickler zusammenzubringen, hoffen sie, dass sie winzige Teams in Silos haben können, die sich jeweils auf ihren eigenen kleinen Mikroservice konzentrieren. Wenn Sie sich in einer derart dysfunktionalen Organisation befinden, ist dies so attraktiv: Sie haben eine viel größere Berechtigung, Personen, die Sie nicht mögen, zu meiden und nicht zu kommunizieren.

Leider wird es zu einem "Laufzeitproblem", denn sobald die Software in der Produktion läuft, wird eine gute Kommunikation genauso wichtig. Die Probleme mit der Organisation - die Teams und wie sie ausgerichtet sind und kommunizieren - manifestieren sich zur "Laufzeit".

Der Punkt meines Tweets war: Wenn Sie ein Menschenproblem haben, wird eine neue Architektur nicht helfen. Es wird nur die Auswirkungen des Problems verzögern. Ich denke, dass die Attraktivität von Mikrodiensten für viele Menschen die Hoffnung ist, diese Probleme auf magische Weise zu lösen.

Meine Frage ist: Was bedeutet es, dass die Umstellung auf Microservices ein Laufzeitproblem verursacht?

Das sagen diese Tweets nicht ! Sie sagen nichts über die Umstellung auf Microservices , noch sagen sie etwas über die Schaffung von Problemen. Sie sagen nur etwas über die Verlagerung von Problemen .

Und sie schränken ihre Behauptungen kontextuell ein, nämlich dass Ihre Organisation nicht richtig funktioniert.

Der erste Tweet sagt also im Grunde genommen zwei Dinge aus:

• "Wenn Ihre Organisation nicht in der Lage ist, komplexe Systeme jetzt ohne Microservices zu entwickeln, kann sie komplexe Systeme nicht auf magische Weise mit Microservices entwickeln" und
• "Die Probleme, die durch diese Unfähigkeit verursacht werden, die jetzt während der Kompilierungszeit, dh während der Entwicklung, auftreten, werden dann während der Laufzeit, dh in der Produktion, auftreten." dysfunktionale Organisationen, die wahrscheinlich ein nicht dem Standard entsprechendes Testregime haben)

Der zweite Tweet besagt, dass die Tatsache, dass sich die Probleme nur in der Produktion manifestieren, dh dort, wo die Kunden sie sehen, ein Merkmal und kein Fehler ist, denn wenn sich die Kunden beschweren, wird dies tendenziell an anderen Orten gehört, als wenn ein Build bricht, nämlich an Orten, die in der Lage sind, etwas gegen die organisatorische Dysfunktion zu unternehmen (z. B. Management auf hoher Ebene). Da es sich bei einer Organisationsstörung in der Regel um ein Versagen des Managements auf hoher Ebene handelt, bedeutet dies, dass unzufriedene Kunden diejenigen schlecht reflektieren, die letztendlich für diese Unzufriedenheit verantwortlich sind, während eine niedrige Codequalität, die durch Versagen des Managements auf höherer Ebene verursacht wird, in der Regel nur die Entwickler schlecht reflektieren, die dies sind jedoch nicht schuld und unfähig, etwas dagegen zu tun.

Der erste Tweet besagt, dass Microservices Probleme, die durch schlechtes Management verursacht wurden, von der Kompilierungszeit, in der nur Entwickler sie sehen, zur Laufzeit verschieben, in der Kunden sie sehen. Der zweite Tweet sagt, dass das eine gute Sache ist, denn dann verletzen die Probleme diejenigen, die für sie verantwortlich sind.

Es wird ein Laufzeitproblem im Gegensatz zu einem Kompilierungsproblem erstellt.

Eine monolithische App ist schwer und teuer zu kompilieren. Aber wenn es einmal kompiliert ist, können Sie ziemlich sicher sein, dass keine extrem dummen Inkompatibilitäten zwischen Komponenten existieren, da das Typsystem sie abfangen kann. Derselbe Fehler in einem System von Mikroservices wird möglicherweise erst angezeigt, wenn zwei bestimmte Komponenten tatsächlich auf eine bestimmte Weise interagieren.

Sowohl in monolithischen Systemen als auch in Mikrodiensten müssen Schnittstellen zwischen den Subsystemen definiert werden. Die Schnittstellen sollten gut gestaltet, gut dokumentiert und so stabil wie möglich sein. Dies ist das gleiche wie in OOP.

Wenn Ihre Organisation dies nicht kann, kann das Problem auch nicht durch Microservices behoben werden. In microservices haben Sie öffentliche Weboberflächen. Sie müssen sich also noch mehr mit dem Interface-Design befassen.

Wenn die Schnittstelle nicht ordnungsgemäß entworfen wurde, treten zwei Arten von Laufzeitproblemen auf:

1. Wenn die Schnittstelle nicht korrekt verwendet wird, erhalten Sie zur Laufzeit einen Fehler, nicht zur Kompilierungszeit.
2. Das Aufrufen einer Webschnittstelle ist sehr langsam, sodass Leistungsprobleme auftreten können.

Ich denke, dass das Produzieren von Laufzeitproblemen nicht der richtige Weg ist, um Kommunikationsprobleme zu den Verantwortlichen zu bringen.