Wie entsteht beim Wechsel zu Microservices ein Laufzeitproblem?

104

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?

Falkenauge
quelle
13
Wenn A in einem Monolyth mit B spricht, kann zumindest die tatsächliche Schnittstelle als kompatibel (durch statische Typisierung) erwiesen werden, was es wahrscheinlicher macht, dass sie auch korrekt ist. In der Regel kommunizieren Microservices über etwas ohne solche Kompilierungszeitüberprüfungen
Richard Tingle
Wenn Sie sich mit den Problemen im Zusammenhang mit der Verwendung von Mikrodiensten befassen, ist der Artikel von Fowler ein Muss. martinfowler.com/articles/microservices.html Ich glaube , dass nicht nur ein Fall von der Kompilierung vs Laufzeit ist wie @ Richard Tingle sagte. Und stimmen Sie nicht wirklich zu, dass ein Produktionsproblem besser ist als eines in der Entwicklung. Microservices können jedoch dazu beitragen, große Projekte auf andere Weise zu skalieren. (Und sind ein Overkill für die meisten kleinen Projekte)
Borjab
2
Dieser Kommentator ist kurzsichtig. Laufzeitproblem => Probleme mit dem Produkt => Unzufriedene Benutzer => Geld verloren.
Philipp
@Philipp: Darum geht es. Kompilieren Sie Zeitprobleme, die durch organisatorische Dysfunktion verursacht werden => niemand kümmert sich darum. Geldverlust durch organisatorische Dysfunktion => verletzt genau diejenigen, die für diese organisatorische Dysfunktion verantwortlich sind. Die Hoffnung: Organisationsstörungen werden schneller behoben.
Jörg W Mittag

Antworten:

194

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.

amon
quelle
13
@JacquesB Ich bin zuversichtlich, dass sich die „organisatorische Dysfunktion“ auf die Unfähigkeit bezieht, ein System zu entwickeln. Der Großteil meiner Antwort bezieht sich auf den Kontext, um zu veranschaulichen, wie man zu einer solchen Schlussfolgerung gelangen kann, ist jedoch meine berufliche Meinung und nicht aus dem Tweet übernommen.
amon
10
"Monolith, der sauber in Komponenten unterteilt ist" - was zum Teufel soll das heißen?
10
Und ganz zu schweigen von der Versionierung von Schnittstellen (Schnittstellen, die sich im Laufe der Zeit ändern).
Peter Mortensen
12
@mobileink Monolith ist hier kein idealer Begriff, da er „keine Architektur“ suggeriert. Ich versuche jedoch, ein System zu vermitteln, das als einzelnes System entwickelt und bereitgestellt wird, im Gegensatz zu einer serviceorientierten Architektur, bei der Teile des Systems unabhängig voneinander bereitgestellt werden können. Bitte bearbeiten Sie den Beitrag, wenn Sie einen besseren Begriff kennen…
amon
7
@amon Wenn man das Wort Monolith hört, kommt man nicht sofort auf die Idee, dass es keine Architektur gibt. Die meisten Gebäude sind Monolithen, ebenso wie die großen Pyramiden Ägyptens und viele andere Gegenstände. Offensichtlich wurden sie als Ganzes entworfen und ausgeliefert. Vielen Softwaresystemen fehlt eine gute Architektur. Der Mangel an guter Architektur scheint jedoch unabhängig davon zu sein, wie sie eingesetzt werden. Sie können einen Teil des Gerüsts eines anderen Projekts ausleihen und es als Architektur bezeichnen (3-Tier, 2-Tier, n-Tier, Mikroservice usw.), dies ist jedoch keine Garantie dafür, dass Sie es gut gemacht haben.
Edwin Buck
215

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.

Paul Stovell
quelle
67
+1. Dies ist als Stack Exchange-Antwort viel besser als als Tweet. :-)
ruakh
3
Das gleiche gilt für alle dynamischen Systeme. Dynamisches Tippen ist sehr nützlich, aber nur, wenn Sie die richtigen Leute haben. "Freiform-Datenbanken" sind sehr nützlich, aber nur, wenn Sie die richtigen Leute haben. Wenn Sie nicht die richtigen Leute haben, delegieren Sie nur die Probleme und lösen sie nicht.
Luaan
2
Ich denke, das ist eine Tautologie. Wenn Menschen das Problem sind, können sich die Probleme überall manifestieren. Ich kann mir nicht vorstellen, eine Lösung mit mehreren Mikrodiensten ohne ordnungsgemäße Integrationstests auszuliefern. In diesem Fall gibt es keine Möglichkeit, eine Lösung mit einem unterstützten Arbeitsablauf zu versenden. Wenn jemand zu Microservices ohne Flow-Test wechselt, insbesondere um Probleme zu verbergen, sind sie das Problem. Könnte auch ungetestete / kaputte Binärdateien versenden. Es erhöht das Problem von Programmierern auf Trooper-Ebene, zu denen es gehört.
Luk32
10
@ luk32 Zum Teil ja, aber das Wesentliche an Microservices, die es für schlechte Teams attraktiv machen, ist, dass Sie Ihre Fähigkeiten und Kommunikationsdefizite für einen längeren Zeitraum unbemerkt lassen. Es geht nicht darum, die Probleme zu haben oder nicht, es geht darum, wann sie auftauchen werden
T. Sar
18
Sehr nette Antwort. Vielen Dank, dass Sie meine Meinung zu Twitter als absolut nutzlos für irgendetwas anderes bestätigt haben, als Menschen zu erregen.
Robert Harvey
43

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.

Jörg W. Mittag
quelle
6
@ Michael Wenn Sie nicht sehen , wie sie die Qualität des Codes auswirken, sollten Sie vielleicht , welche Auswirkungen - wenn überhaupt - Management an hat jeder Teil von der Qualität der Produkte ihr Geschäft schafft.
WJL
30
@Michael: Alles wird letztendlich durch ein übergeordnetes Management verursacht. Wird eine niedrige Codequalität durch unmögliche Fristen verursacht? Wer setzt diese Fristen? Wer sagt denen, die diese Fristen setzen, um diese Fristen zu setzen? Wird eine niedrige Codequalität von inkompetenten Entwicklern verursacht? Wer hat diese inkompetenten Entwickler eingestellt? Wer hat diejenigen eingestellt, die diese inkompetenten Entwickler eingestellt haben? Liegt es an unzureichenden Werkzeugen? Wer kauft diese Werkzeuge? Wer genehmigt das Budget, um diese Werkzeuge zu kaufen? Es wird durch dumme Architektur verursacht? Wer hat den Architekten engagiert? Wer hat ihn beauftragt? Diese Tweets waren speziell im Kontext…
Jörg W Mittag
13
… Organisatorische Dysfunktion. Nun, die Organisation zum Funktionieren zu bringen, ist so ziemlich DIE Aufgabe des Managements auf höherer Ebene. Das ist , was Management ist .
Jörg W Mittag
4
Obwohl dies wahrscheinlich langfristig funktionieren wird, scheint die Idee, die Probleme Ihres Unternehmens durch Beeinflussung der Kunden zu lösen, nicht richtig zu sein.
Stijn de Witt
1
@ JörgWMittag Ich halte es nicht für vernünftig, zu behaupten, dass schlechter Code, der von schlechten Entwicklern geschrieben wurde, die Schuld der Leute ist, die diese schlechten Entwickler eingestellt haben, und nicht der schlechten Entwickler selbst. Es könnte letztlich in der Verantwortung des Managements sein, aber es wird verursacht von den Entwicklern.
Miles Rout
9

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.

Kilian Foth
quelle
9
Dies scheint davon auszugehen, dass "monolithische" Anwendungen immer statisch typisiert sind. Was ist mit dynamisch getippten Sprachen? Und was ist mit statisch typisierten Service-Interfaces?
JacquesB
1
@JacquesB OTOH, ich kann mir genau null dynamisch typisierte kompilierte Sprachen vorstellen.
immibis
2
@JacquesB JavaScript und Python werden nicht kompiliert. Es sei denn, Sie zählen interne Interpreterstrukturen als Kompilierungsziel. In diesem Fall wird jede Sprache kompiliert.
immibis
3
@immibis: Jede einzelne derzeit vorhandene ECMAScript-Implementierung verfügt über mindestens einen Compiler. V8 zum Beispiel hat zwei Compiler und genau null Interpreter, es interpretiert nie , es kompiliert immer in binären Maschinencode. Ich glaube, SpiderMonkey hat vier Compiler und einen Interpreter, aber dieser Interpreter interpretiert ECMAScript nicht. SpiderMonkey interpretiert ECMAScript nie , es kompiliert es immer zuerst in SpiderMonkey-Bytecode, den es dann möglicherweise weiter in binären systemeigenen Code kompiliert. Alle derzeit vorhandenen Python-, Ruby- und PHP-Implementierungen verfügen über Compiler.
Jörg W. Mittag
12
@LieRyan Sie sind ernsthaft verwirrt, wenn Sie glauben, dass die Typinferenz der dynamisch getippten entspricht und / oder dass Haskell dynamisch getippt ist.
Derek Elkins
2

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.

Bernie
quelle