Die letzten drei Beiträge unserer Post-Serie haben sich ganz um den Interact-Zwischenstopp gedreht. Der Communicate-Zwischenstopp steht in einer sehr engen Verbindung zum Interact-Zwischenstopp.
Im ersten Interact-Beitrag wurde die Abgrenzung zwischen dem Interact- und dem Communicate-Zwischenstopp bereits deutlich gemacht. Wie dort beschrieben, widmen wir uns also in diesem Zwischenstopp darum, wie Systeme bzw. Teilsysteme miteinander kommunizieren.
Was kann ich mir von diesem Zwischenstopp erwarten?
Im Communicate-Zwischenstopp sind folgende Themen enthalten:
Synchrone Kommunikation
REST
RPC
Asynchrone Kommunikation
Point-to-Point
Publish-Subscribe
Transaktionen
Choreographie
Orchestrierung
Dieser Zwischenstopp kümmert sich dabei jedoch nicht um eine starre Auswahl von Kommunikationstechnologien. Vielmehr steht im Fokus, dass auf Basis der funktionalen (Fachdomäne) und nicht-funktionalen Anforderungen (Architekturziele) flexibel die passenden Mittel gewählt werden.
Die sinnvollste Kommunikationstechnologie zwischen zwei oder mehreren Teilsystemen ergbit sich dabei meistens anhand der gewählten Transaktionspatterns, um verteilte Business-Transaktionen ideal zu realisieren.
Anzumerken ist an dieser Stelle natürlich, dass im Zuge des Architect-Zwischenstopps, mit den Mitteln von Domain Driven Design, unnötig verteilte Business-Transaktionen bereits verhindert werden können. Die "Irrtümer der verteilten Datenverarbeitung" skizzieren anschaulich warum das äußerst sinnvoll ist.
Warum soll ich bei diesem Zwischenstopp halt machen?
Dieser Zwischenstopp hilft dabei, in Kombination mit dem Architect-Zwischenstopp, potentiell "gefährliche" Kommunikationswege zu erkennen und proaktiv zu vermeiden. Damit einher geht auch, dass der Bau eines verteilten Monolithen verhindert werden kann.
In den vorhergehenden Beiträgen wurde ausgiebig das Thema Service Mesh beschrieben. Oftmals sehen wir leider, dass versucht wird mithilfe eines Service Mesh einen verteilten Monolithen in den Griff zu bekommen. Teilweise gelingt das dank der ausgefeilten Möglichkeiten eines Service Mesh auch, jedoch gilt es zu bedenken, dass es sich dabei dann lediglich um eine Bekämpfung von Symptomen handelt und nicht die eigentliche Problemursache löst.
Die Resilienz des Gesamtsystems wird zwar in gewissen Situationen verbessert, aber eben bei weitem nicht in allen. Damit einher gehen dann Problemsituationen zu absolut unerwarteten Zeitpunkten. Daher ist es notwendig, die Gesamtsituation zu betrachten, um nachhaltige Lösungen zu finden.
Damit schließt sich nun der Kreis in Richtung Interact- und Architect-Zwischenstopp. Basierend auf den Erkenntnissen aus dem Architect-Zwischenstopp können die passenden Kommunikationstechnologien und Transaktionspattern gewählt werden, die Kopplung zwischen Teilsystemen reduziert werden und in Kombination mit modernen Technologien wie bspw. eines Services Meshes die Resilienz des Gesamtsystems auf ein extrem hohes Niveau gehoben werden.
Wie läuft dieser Zwischenstopp ab?
Eine Context Map gibt bereits Hinweise darauf wie sich die Kommunikation zwischen Teilsystem darstellen wird:
Welche Teilsysteme stehen in einer fachlichen Verbindung?
Welche Art von fachlicher Verbindung herrscht vor (Customer-Supplier, Partnership, ...)?
Wer ist der "führende" Teil eines Kommunikationsweges (upstream/downstream)?
Aus wievielen lokalen Transaktionen besteht eine verteilte Business-Transaktion?
Die nachfolgende Context Map skizziert das anhand einer Sequenz aus dem Film "Zurück in die Zukunft". Und soll damit verdeutlichen, wie die Context Map auf die Betrachtung der Gesamtsituation einzahlt:
Der zweite Teil der Betrachtung des Gesamtsystems ist der technische Teil. Hierbei geht es vorrangig darum, auf Basis der Architekturziele und des CAP-Theorems das geeignete Transaktionspattern zu finden. Dazu zählen:
Darauf aufbauend wird eine nachvollziehbare Entscheidung über den Einsatz der konkreten Kommunikationstechnologie ermöglicht.
Somit wären wir wieder am Ende eines Zwischenstopps angelangt und bereit die Reise zum nächsten Zwischenstopp fortzusetzen. Gerne nehme ich an der Stelle eure Vorschläge für den nächsten Zwischenstopp entgegen.
Einfach eine E-Mail an konrad.renner@fullstacks.eu 😉