Die Kladde benutzt Entwurfsmuster, seit es sie gibt, auch wenn sie nicht immer so hießen. Die Bestätigungsmail einer Buchung geht seit K2 über eine Outbox. Der Abruf bei TED wiederholt vorübergehende Fehler mit dem Standard-Handler aus K3. Der nächtliche Import legt seine Rohdaten in Blob Storage und schickt über Service Bus nur den Verweis. Die Vertriebspipeline trennt seit Modul 4.4 Schreiben und Lesen. Jedes davon ist ein Muster aus einem Katalog, den Microsoft im Azure Architecture Center pflegt.

Lektion 4.11.1 hat Entwurfsmuster als dritte Ebene neben Architekturstil und Code-Architektur eingeordnet: Ein Stil sagt, wie das ganze System gebaut ist, ein Muster löst ein bestimmtes, wiederkehrendes Problem darin. Diese Lektion geht den Katalog in der Breite durch, nicht alphabetisch, sondern nach dem Problem: Zuverlässigkeit, Daten, Nachrichten, Entwurf. Zu jedem Muster lesen Sie, welches Problem es löst, wie, was es kostet und wann Microsoft davon abrät, und dazu, ob und wo die Kladde es schon benutzt.

Am Ende legen Sie eine Musterkarte an: jedes Muster, das die Kladde benutzt, mit der Stelle im Code, und zwei Muster, die fehlen, mit einer Begründung, ob sie sich lohnen. Gebaut wird dabei nichts Neues. Ein kleines Programm zeigt eines der fehlenden Muster in Aktion.

Der Katalog und wie man ihn liest

Der Katalog „Cloud design patterns“ im Azure Architecture Center umfasst gut vierzig Muster. Microsoft beschreibt sie ausdrücklich unabhängig von einer Technik: Sie gelten in Azure, in anderen Clouds und im eigenen Rechenzentrum. Die Beispiele auf den Seiten benutzen Azure-Dienste, die Muster selbst nicht.

Jede Seite hat denselben Aufbau, und wer ihn kennt, liest schneller:

Abschnitt Was darin steht Wofür Sie ihn brauchen
Context and problem die Lage, in der das Muster hilft prüfen, ob Ihr Problem dasselbe ist
Solution der Mechanismus, oft mit Diagramm verstehen, was gebaut wird
Issues and considerations (auch „Problems and considerations“) was man beim Bauen bedenken muss die Abwägungen für Ihr ADR
When to use this pattern wann es passt, und wann ausdrücklich nicht die Gegenprobe
Workload design welche Säulen des Well-Architected Framework es stützt die Verbindung zu Lektion 4.7.1
Example eine Umsetzung mit Azure-Diensten Anregung, keine Vorlage

Drei Ratschläge stehen auf der Übersichtsseite, und sie sind wichtiger als jedes einzelne Muster:

  • Nach dem Problem wählen, nicht nach der Technik. Am Anfang steht eine Einschränkung oder ein Risiko der eigenen Arbeitslast: ein Dienst, der unter Last ausfällt, ein Datenspeicher, der mit dem Lesen nicht nachkommt, eine Abhängigkeit, der man nicht ganz trauen kann. Ein Muster passt, wenn seine Problembeschreibung zu diesem Problem passt und Sie mit seinen Abwägungen leben können.
  • Jedes Muster hat einen Preis. Microsoft schreibt dazu, man solle sich darauf konzentrieren, warum man ein Muster wählt, nicht wie man es baut. Ein Muster, dessen Preis niemand kennt, ist eine Mode.
  • Muster lassen sich kombinieren. Die Übersichtsseite nennt vier Paare: Retry mit Circuit Breaker, Queue-Based Load Leveling mit Competing Consumers, die drei Gateway-Muster hinter einem gemeinsamen Endpunkt, und Saga auf Compensating Transaction.

Die Seite erinnert außerdem an die Irrtümer verteilten Rechnens: dass das Netz zuverlässig sei, die Latenz null, die Bandbreite unbegrenzt, das Netz sicher, die Topologie unveränderlich, dass es einen einzigen Administrator gebe, dass Versionen von Komponenten einfach zu verwalten seien und dass sich Beobachtbarkeit auf später verschieben lasse. Die Muster dieser Lektion sind Antworten auf diese Irrtümer. Keines hebt sie auf, jedes macht einen davon bewusst.

Zu den Namen: Die Gliederung dieses Kurses nennt ein Muster „Gateway Routing und Aggregation“. Im Katalog stehen heute drei getrennte Einträge, Gateway Routing, Gateway Aggregation und Gateway Offloading, und die Übersichtsseite empfiehlt, sie hinter einem gemeinsamen Gateway-Endpunkt zu schichten. Diese Lektion benutzt die Namen, wie der Katalog sie heute schreibt, englisch, damit Sie die Seiten finden.

Einige Muster des Katalogs kennen Sie schon aus eigenen Lektionen und finden sie hier nicht noch einmal: Event Sourcing (Modul 4.4), Idempotent Consumer (Lektion 4.6.3, die Inbox), Anti-Corruption Layer (Lektion 4.6.5), Deployment Stamps (Lektion 4.7.6), Rate Limiting und Throttling (K3, Lektion 3.9.4), Strangler Fig (Lektion 4.3.7 und gleich in 4.11.6) und Saga mit Compensating Transaction (Lektion 4.12.4). Die Transactional Outbox aus Lektion 4.6.2 hat keine eigene Seite im Katalog; Microsoft beschreibt sie in einem Leitfaden zu Cosmos DB.