Dies ist ein kurzer Exkurs in der aktuellen Artikelserie darüber, wie die Einführung von Diensten für verschiedene Unternehmen vermieden werden kann. Ein interessantes Gespräch beim Abendessen führte zu Gedanken, die ich aufschreiben wollte.

Amdahls Gesetz

1967 sprach sich Gene Amdahl gegen Parallel Computing aus. Er argumentierte, dass das Produktivitätswachstum begrenzt sei, da nur ein Teil der Aufgabe parallelisiert werden könne. Die Größe des restlichen "sequentiellen Teils" unterscheidet sich in verschiedenen Aufgaben, ist aber immer vorhanden. Dieses Argument wurde als das Gesetz von Amdal bekannt.

Wenn Sie ein Diagramm der "Beschleunigung" der Aufgabe in Abhängigkeit von der Anzahl der ihr zugewiesenen Parallelprozessoren erstellen, wird Folgendes angezeigt:


Dies ist ein asymptotischer Graph für ein Fragment, das nicht parallelisiert werden kann (der „sequentielle Teil“), daher gibt es eine Obergrenze für die maximale Beschleunigung

Von Amdal nach USL

Das Interessante an Amdals Gesetz ist, dass es 1969 tatsächlich nur sehr wenige Multiprozessorsysteme gab. Die Formel basiert auf einem anderen Prinzip: Wenn der sequentielle Teil der Aufgabe gleich Null ist, ist dies nicht eine Aufgabe, sondern mehrere.

Neil Gunther erweiterte Amdahls Gesetz auf der Grundlage von Beobachtungen der Leistungsmessungen vieler Maschinen und leitete das Universal Scalability Law (USL) ab. Es werden zwei Parameter verwendet: einer für "Wettbewerb" (ähnlich dem sequentiellen Teil) und der zweite für "Inkonsistenz" (Inkohärenz). Inkonsistenz hängt mit der Zeit zusammen, die für die Wiederherstellung der Konsistenz aufgewendet wird, dh mit einem allgemeinen Überblick über die Welt der verschiedenen Prozessoren.

In einer CPU tritt aufgrund von Caching ein Verhandlungsaufwand auf. Wenn ein Kern eine Cache-Zeile ändert, weist er die anderen Kernel an, diese Zeile aus dem Cache abzurufen. Wenn jeder dieselbe Zeile benötigt, verbringt er Zeit damit, sie aus dem Hauptspeicher zu laden. (Dies ist eine leicht vereinfachte Beschreibung ... aber in einem genaueren Wortlaut fallen immer noch die Verhandlungskosten an).

Alle Datenbankknoten verursachen Koordinierungskosten aufgrund von Übereinstimmungsalgorithmen und Speichern der Datensequenz. Die Strafe wird beim Ändern von Daten (wie bei Transaktionsdatenbanken) oder beim Lesen von Daten bei letztendlich vereinbarten Repositories gezahlt.

USL-Effekt

Wenn Sie abhängig von der Anzahl der Prozessoren ein USL-Diagramm erstellen, wird eine grüne Linie angezeigt:


Die violette Linie zeigt an, dass Amdahls Gesetz dies vorhersagen würde

Beachten Sie, dass die grüne Linie einen Spitzenwert erreicht und dann abnimmt. Dies bedeutet, dass es eine bestimmte Anzahl von Knoten gibt, an denen die maximale Leistung erzielt wird. Fügen Sie weitere Prozessoren hinzu - und die Leistung wird reduziert . Ich habe das in echten Stresstests gesehen.

Menschen möchten oft die Anzahl der Prozessoren erhöhen und die Produktivität steigern. Es gibt zwei Möglichkeiten, dies zu tun:

1. Reduzieren Sie den sequentiellen Teil
2. Genehmigungskosten reduzieren

USL in menschlichen Gruppen?

Versuchen wir die Analogie. Wenn die rechnerische „Aufgabe“ ein Projekt ist, können wir die Anzahl der Personen im Projekt als die Anzahl der „Prozessoren“ darstellen, die die Arbeit ausführen.

In diesem Fall ist der sequentielle Teil eine Arbeit, die nur schrittweise nacheinander ausgeführt werden kann. Dies mag ein Thema für einen zukünftigen Artikel sein, aber jetzt interessiert uns das Wesentliche des sequentiellen Teils nicht mehr.

Wir scheinen eine direkte Analogie zu den Kosten der Versöhnung zu sehen. Unabhängig von der Zeit, die Teammitglieder für die Wiederherstellung einer gemeinsamen Weltanschauung aufwenden, sind die Kosten für die Ausrichtung vorhanden.

Für fünf Personen in einem Raum sind diese Kosten minimal. Fünf-Minuten-Zeichnung mit einem Marker an der Tafel etwa einmal pro Woche.

Für ein großes Team in mehreren Zeitzonen kann die Geldbuße wachsen und sich formalisieren. Dokumente und exemplarische Vorgehensweisen. Präsentationen für das Team und so weiter.

In einigen Architekturen ist die Abstimmung nicht so wichtig. Stellen Sie sich ein Team mit Mitarbeitern auf drei Kontinenten vor, die jedoch jeweils an einem Dienst arbeiten, der Daten in einem genau definierten Format verwendet und Daten in einem genau definierten Format erstellt. Sie benötigen keine Konsistenz in Bezug auf Änderungen in Prozessen, aber sie benötigen Konsistenz in Bezug auf Änderungen in Formaten.

Manchmal können Tools und Sprachen die Kosten für die Abstimmung ändern. Eines der Argumente für statische Typisierung ist, dass es hilft, in einem Team zu interagieren. Codetypen sind im Wesentlichen ein Mechanismus zum Übersetzen von Änderungen in einem Modell der Welt. In einer dynamisch typisierten Sprache benötigen wir entweder sekundäre Artefakte (Komponententests oder Chat-Nachrichten) oder wir müssen Grenzen erstellen, an denen einige Abteilungen nur sehr selten die Konsistenz mit anderen wiederherstellen.

Alle diese Methoden zielen darauf ab, die Koordinierungskosten zu senken. Denken Sie daran, dass eine übermäßige Skalierung zu einer Verringerung des Durchsatzes führt. Wenn Sie also hohe Koordinationskosten und zu viele Personen haben, arbeitet das gesamte Team langsamer. Ich habe Teams gesehen, in denen es den Anschein hatte, als könnten wir die Hälfte der Leute abschneiden und doppelt so schnell arbeiten. Die USL- und Abstimmungskosten helfen jetzt zu verstehen, warum dies geschieht - es ist mehr als nur Müllabfuhr. Es geht darum, den Aufwand für den Austausch mentaler Modelle zu verringern.

In The Loop of Fear bezog ich mich auf Codebasen, in denen Entwickler über die Notwendigkeit umfangreicher Änderungen Bescheid wussten, aber Angst hatten, versehentlich Schaden anzurichten. Dies bedeutet, dass das überhöhte Team noch keinen Konsens erreicht hat. Es scheint sehr schwierig, sich nach dem Verlust zu versöhnen. Dies bedeutet, dass die Kosten für die Koordinierung nicht ignoriert werden können.

USL und Microservices

Meiner Meinung nach erklärt USL das Interesse an Microservices. Indem Sie ein großes System in immer kleinere Teile aufteilen, die unabhängig voneinander bereitgestellt werden, reduzieren Sie den sequentiellen Teil der Arbeit. In einem großen System mit einer großen Anzahl von Teilnehmern hängt der sequentielle Teil vom Aufwand für die Integration, den Test und die Bereitstellung ab. Der Vorteil von Microservices besteht darin, dass keine Integrationsarbeiten, Integrationstests oder Verzögerungen bei der synchronisierten Bereitstellung erforderlich sind.

Aufgrund der Kosten für den Abgleich erhalten Sie möglicherweise nicht die gewünschte Beschleunigung. Vielleicht ist die Analogie hier etwas angespannt, aber ich denke, dass es möglich ist, Schnittstellenänderungen zwischen Microservices als eine Abstimmung zwischen Teams zu betrachten. Wenn dies zu viel ist, erhalten Sie nicht die gewünschten Vorteile von Microservices.

Was tun?

Mein Vorschlag: Schauen Sie sich die verwendete Architektur, Sprache, Tools und das Team an. Überlegen Sie, wo Zeit für Versöhnung verloren geht, wenn Menschen Änderungen am systemischen Modell der Welt vornehmen.

Suchen Sie nach Lücken . Lücken zwischen den internen Grenzen des Systems und Teilungen innerhalb des Teams.

Verwenden Sie die Umgebung, um Änderungen zu kommunizieren, sodass der Abstimmungsprozess für alle und nicht für jeden Einzelnen stattfindet.

Sehen Sie sich die Kommunikation Ihres Teams an. Wie viel Zeit und Mühe ist erforderlich, um die Konsistenz sicherzustellen? Nehmen Sie vielleicht kleine Änderungen vor und reduzieren Sie den Bedarf?