Verteilungsdiagramm-Beispiele

Das Diagramm oben ist das, welches man aus dem Kopf zeichnen können sollte. Ein Browser, ein Webserver, der TLS terminiert, ein Anwendungsserver, eine Datenbank. Drei Kommunikationspfade mit Protokoll und Port und drei Artefakte, auf die Knoten gelegt, die sie ausführen.

Zwei Entscheidungen darin verdienen einen Namen. Erstens sind die Protokollbeschriftungen der Grund, warum das Diagramm nützlich ist: HTTPS, HTTP/8080, TCP/5432 ist der gesamte Inhalt der meisten Sicherheitsprüfungen, und ein Diagramm ohne sie sind vier Kästen, die jeder hätte raten können. Zweitens sind die Artefakte echte Dateinamen - orders.jar, nicht „Anwendung“ - denn ein Verteilungsdiagramm handelt von physischen Dingen, und ein Build erzeugt Dateien mit Namen.

Container lassen Leute zögern, weil ein Container zugleich etwas Laufendes und etwas Gebautes ist. UML trennt das bereits: der laufende Container ist eine Ausführungsumgebung, also ein Knoten, und das Image, aus dem er startete, ist ein Artefakt, das darauf deployt wird.

An der Form dieses Diagramms unterscheidet sich nichts vom dreischichtigen, und das ist der Punkt: die Laufzeit hat sich geändert, die Notation nicht. Der Load Balancer ist ein «device», weil er Infrastruktur ist, in die Sie nicht deployen. Der Ingress-Controller und der Pod sind «execution environment», weil in ihnen anderes läuft. Der Image-Tag orders:1.4.2ist ein Artefakt, weil ein Build ihn erzeugt hat, und die Version in die Beschriftung zu setzen ist das, was das Diagramm „was läuft gerade in Produktion“ beantworten lässt.

Die verwaltete Datenbank sitzt als schlichtes Gerät am Rand. Das ist die ehrliche Zeichnung: man deployt keine Artefakte auf einen Dienst, den jemand anders betreibt, und so zu tun, als sei das Schema „auf RDS“ installiert, stimmt nur in dem Sinn, dass es dort einmal angewandt wurde.

Der häufigste Grund, ein Verteilungsdiagramm zu öffnen, ist herauszufinden, was passiert, wenn ein Kasten stirbt. Diese Frage hat eine Form, und es lohnt sich, sie ausdrücklich zu zeichnen, statt sie einer Fußnote zu überlassen.

Drei Anwendungsknoten hinter einem Load Balancer, alle auf eine einzige Primärdatenbank schreibend. So gezeichnet ist der Single Point of Failure sichtbar, ohne dass ihn jemand aussprechen muss: die Anwendungsschicht fächert auf, die Datenschicht nicht. Das ist ein Satz, auf den jemand reagieren wird, und er hat keine zusätzliche Notation gekostet.

Ändert sich die Anzahl zur Laufzeit, ersetzen Sie die drei Knoten durch einen mit Multiplizität - app-node [3..*] - statt eine willkürliche Zahl zu zeichnen. Ein Diagramm, das genau drei behauptet, ist beim ersten Skalieren der Gruppe falsch, und ein als falsch bekanntes Diagramm wird nicht mehr konsultiert.

Jedes Verteilungsdiagramm, das nutzlos wird, wird es auf dieselbe Weise: jemand hat immer weiter Knoten ergänzt. Die Disziplin besteht darin, zu entscheiden, wofür das Diagramm da ist, bevor der zweite Kasten fällt.

Brauchen Sie das Gegenstück, das die Software statt der Maschinen zeigt, ist das ein Komponentendiagramm. Die beiden werden meist als Paar gezeichnet, und das Verteilungsdiagramm ist das kürzere.