it-swarm.com.de

Wie verursacht die Umstellung auf Microservices ein Laufzeitproblem?

Folgendes Kommentator schreibt :

Microservices verschieben Ihre organisatorische Dysfunktion von einem Problem mit der Kompilierungszeit auf ein Problem mit der Laufzeit.

Dies Kommentator erweitert zu dem Thema, das sagt:

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

Jetzt verstehe das mit microservices du:

  • erhöhen Sie möglicherweise die Latenz Ihres Durchsatzes - ein Problem für Produktion und Laufzeit.
  • 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önnen durch Schnittstellenfehlanpassungen aufgehalten werden (siehe Netzwerkschnittstellen). Wenn jedoch blaugrüne Bereitstellungen funktionieren, ist dies eher ein Problem zur Laufzeit.

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

104
hawkeye

Ich habe ein Problem. Verwenden wir Microservices! Jetzt habe ich 13 verteilte Probleme.

Es ist eine gute Idee, Ihr System in gekapselte, zusammenhängende und entkoppelte Komponenten zu unterteilen. Damit können Sie verschiedene Probleme separat angehen. In einer monolithischen Bereitstellung ist dies jedoch sehr gut möglich (siehe Fowler: Microservice Premium ). Immerhin ist dies das, was OOP seit vielen Jahrzehnten lehrt! Wenn Sie sich entscheiden, Ihre Komponenten in Microservices umzuwandeln, erhalten Sie keinen architektonischen Vorteil. Sie gewinnen eine gewisse Flexibilität hinsichtlich der Wahl der Technologie und möglicherweise (aber nicht unbedingt!) Skalierbarkeit. Sie haben jedoch garantiert Kopfschmerzen, die sich aus (a) der verteilten Natur des Systems und (b) der Kommunikation zwischen Komponenten ergeben. Wenn Sie sich für Microservices entscheiden, haben Sie andere Probleme, die so dringlich sind, dass Sie sind bereit, trotz dieser Probleme Microservices zu nutzen.

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 Der Schmerz wird ziemlich offensichtlich sein. Im Idealfall wird der Code einfach nicht kompiliert, wenn er schrecklich kaputt ist. Bei Microservices kann jeder Dienst jedoch separat entwickelt werden, möglicherweise sogar in verschiedenen Sprachen. Probleme bei der Interaktion von Komponenten werden erst sichtbar, wenn Sie Ihre Komponenten integrieren. Zu diesem Zeitpunkt ist es bereits zu spät, die Gesamtarchitektur zu reparieren.

Die Hauptursache für Fehler ist die Nichtübereinstimmung der Schnittstelle. Möglicherweise gibt es offensichtliche Fehler wie einen fehlenden Parameter oder subtilere Beispiele wie das Vergessen, einen Fehlercode zu überprüfen, oder das Vergessen, eine Vorbedingung zu überprüfen, bevor eine Methode aufgerufen wird. Durch statische Typisierung werden solche Probleme so früh wie möglich erkannt: In Ihrem IDE und im Compiler vorher wird der Code jemals ausgeführt. 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. Wenn Sie nicht zu einer formalen Dienstbeschreibungssprache 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, so dass möglicherweise noch Probleme in der Produktion bestehen. Wann wird dieses Problem offensichtlich? Nur wenn dieser fehlerhafte Pfad zur Laufzeit in der Produktion eingeschlagen wird. Die Vorstellung, dass Produktprobleme zu einem schnelleren Feedback führen würden, ist komisch gefährlich falsch, es sei denn, Sie amüsieren sich über die Möglichkeit eines Datenverlusts.

197
amon

Der erste Tweet war meins, also werde ich ihn erweitern:

Angenommen, Sie haben 100 Entwickler, die an einer monolithischen Anwendung arbeiten. Das sind zu viele Menschen, um effektiv miteinander zu kommunizieren. Daher muss das Unternehmen hart arbeiten, um 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. - daher dauert es ewig, bis sie etwas versenden. Es ist ein "Problem der Kompilierungszeit" in dem Sinne, dass die Funktionsstörung offensichtlich ist, bevor die Software erstellt wird. Das Projekt ist wahrscheinlich ein Todesmarsch oder wird nie ausgeliefert ("kompilieren").

Ich denke, viele Menschen fühlen sich von Mikrodiensten angezogen und ziehen zu ihnen, nicht wegen der inhärenten technischen/architektonischen Vorteile, sondern weil sie dadurch die organisatorische Dysfunktion ignorieren können. Anstatt zu versuchen, 100 Entwickler zusammenzubringen, hoffen sie, dass sie winzige Teams in Silos arbeiten lassen können, die sich jeweils auf ihren eigenen kleinen Mikrodienst konzentrieren. Wenn Sie sich in einer so dysfunktionalen Organisation befinden, ist dies so attraktiv: Es gibt Ihnen eine viel größere Erlaubnis, Menschen zu meiden, die Sie nicht mögen, 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 das, was Sie haben, ein people Problem ist, wird eine neue Architektur nicht helfen. Es wird nur die Auswirkungen des Problems verzögern. Ich denke, die Attraktivität von Mikrodiensten für viele Menschen ist die Hoffnung, dass sie diese Menschenprobleme auf magische Weise lösen.

218
Paul Stovell

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

Das ist nicht was diese Tweets sagen! Sie sagen nichts über das Verschieben von zu Microservices, noch sagen sie etwas über Erstellen Probleme. Sie sagen nur etwas über Verschiebungsprobleme.

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

Also, was der erste Tweet im Grunde sagt, sind zwei Dinge:

  • "Wenn Ihr Unternehmen jetzt nicht in der Lage ist, komplexe Systeme ohne Microservices zu entwickeln, kann es auf magische Weise keine komplexen Systeme mit Microservices entwickeln."
  • "Die Probleme, die durch diese Unfähigkeit verursacht werden und jetzt während der Kompilierungszeit, dh während der Entwicklung, auftreten, treten dann zur Laufzeit, dh in der Produktion, auf" (technisch gesehen könnten sie auch während des Testens auftreten, aber denken Sie daran, dass sich das Angebot selbst einschränkt an dysfunktionale Organisationen, die wahrscheinlich ein unterdurchschnittliches Testregime haben)

Der zweite Tweet besagt, dass die Tatsache, dass sich die Probleme nur in der Produktion manifestieren, dh wo Kunden sie sehen, eine Funktion ist, kein Fehler, denn wann Kunden beschweren sich, dass dies an anderen Stellen zu hören ist, als wenn ein Build kaputt geht, und zwar an Orten, die in der Lage sind, etwas gegen die organisatorische Funktionsstörung zu tun (z. B. Management auf hoher Ebene). Da organisatorische Funktionsstörungen in der Regel ein Fehler des High-Level-Managements sind, bedeutet dies, dass unzufriedene Kunden diejenigen, die letztendlich für diese Unzufriedenheit verantwortlich sind, schlecht reflektieren, während eine niedrige Codequalität, die durch Managementfehler auf höherer Ebene verursacht wird, sich normalerweise nur schlecht auf die Entwickler auswirkt, die dies sind jedoch nicht schuld und nicht in der Lage, etwas dagegen zu tun.

Der erste Tweet besagt also, dass Microservices Probleme, die durch schlechtes Management verursacht werden, von der Kompilierungszeit, wo nur Entwickler sie sehen, zur Laufzeit verschieben, wo 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.

43
Jörg W Mittag

Es entsteht ein Laufzeitproblem im Gegensatz zu einem kompilieren - Zeitproblem.

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

9
Kilian Foth

Sowohl in monolithischen Systemen als auch in Microservices müssen Sie Schnittstellen zwischen den Subsystemen definieren. 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, wird das Problem auch von Microservices nicht gelöst. In Microservices haben Sie öffentliche Webschnittstellen. Sie müssen sich also noch mehr um das Interface-Design kümmern.

Wenn die Schnittstelle nicht richtig gestaltet ist, treten zwei Arten von Laufzeitproblemen auf:

  1. Wenn die Schnittstelle nicht richtig verwendet wird, wird zur Laufzeit ein Fehler angezeigt, nicht zur Kompilierungszeit.
  2. Das Aufrufen einer Weboberfläche ist recht langsam, sodass Leistungsprobleme auftreten können.

Ich denke, das Erstellen von Laufzeitproblemen ist nicht der richtige Weg, um organisatorische Probleme mit den Verantwortlichen zu kommunizieren.

2
bernie