Unsere Post-Serie hat in den letzten Beiträgen den Interact- und Communicate-Zwischenstopp beschrieben. Zu diesem Themenkreis passend ist der Exchange Zwischenstopp, in dem wir die Themengebiete Datenaustauschformate, persistente Datenhaltung oder auch Caching näher beleuchten.
Was kann ich mir von diesem Zwischenstopp erwarten?
Im Exchange-Zwischenstopp sind folgende Themen enthalten:
Datenformate & Read/Write-Modelle
Persistierung von Daten
Caching von Daten
Mehrmandantenfähigkeit
Der Fokus dieses Zwischenstopps liegt voll darauf, wie Daten zwischen (Teil-)Systemen ausgetauscht werden und wie bzw. wo Daten persistiert oder gecached werden.
In verteilten Architekturen, mit lose gekoppelten Systemen, sollte auch die Persistierung von Daten lose gekoppelt sein. Grundsätzlich empfehlen wir daher auf das Pattern "Database per Service" zu setzen. Dieses Pattern ist sehr gut bei Greenfield-Projekten einsetzbar, in Unternehmen mit gewachsenen Datenbestand und Datenverwaltung würde ein unkoordinierter Umstieg auf dieses Patterns jedoch ein erhebliches Betriebsrisiko darstellen. Wir unterstützen bei diesen Zwischenstopp daher nicht nur bei der Einführung von cloud nativen Pattern und Speichermöglichkeiten, sondern auch bei der Transition dorthin.
Datenformate bilden die Grundlage für die Interoperabilität zwischen Systemen. Unser Zugang zu diesem Thema ist, überall wo möglich, auf bereits existierende Standards zu setzen und diese, dort wo sinnvoll, zu erweitern.
Am Beispiel von Event-basierter Kommunikation zwischen Systemen sollen folgende Fragestellungen die Arbeitsweise dieses Zwischenstopps verdeutlichen:
Definition des Event-Formats je Kommunikationsstrang:
Event-Notification vs Event-Carried-State-Transfer vs Domain-Event
Mögliche Einführung von separaten Read-Modellen zu bestehenden Write-Modell:
Rücksichtnahme auf Patterns für verteilte Transaktionen (bspw. Event Sourcing vs Outbox Pattern)
Ablage in distributed Caches vs. eigene persistente Datenhaltung
Warum soll ich bei diesem Zwischenstopp halt machen?
Wie bereits eingangs erwähnt ist es unerlässlich für die Interoperabilität von Systemen, dass die Systeme sich gegenseitig "verstehen" und das wird eben damit ermöglicht, das Formate von allen beteiligten Systemen serialisiert und de-serialisert werden können.
Gut überlegte Datenformate tragen weiters dazu bei, dass sowohl der Datenaustausch, als auch die Datenhaltung nachhaltig ist und bilden damit die Basis von langlebigen Systemen (im positiven Sinn gemeint 😉). Instabile Formate oder exotische Persistenztechnologien können im Umkehrschluss massive Auswirkungen auf die Wartbarkeit, Stabilität, Observability und auch Performance haben.
Weiters trägt dieser Zwischenstopp dazu bei, die Möglichkeiten von dynamischer Skalierung voll auszuschöpfen. Es ist bspw. nahezu unmöglich ein System dynamisch zu skalieren, wenn die Integration von Systemen auf Datenbankebene vollzogen (gegenseitiges Locking, unklare Datenhoheit, usw.) sind.
Wie läuft dieser Zwischenstopp ab?
Wie im vorhergehenden Absatz angedeutet, ist die Integration von Systemen auf Datenbankebene äußerst problematisch. Ein Aspekt dieses Zwischenstopps ist es also, falls eine derartige Konstellation vorliegt, die Integration von Systemen auf Datenbankebene zu überwinden und diese in Kommunkationspfade überzuleiten, die eine cloud native Architektur ermöglichen.
System Context-Diagramme geben Informationen darüber, welche Datenformate bei der Kommunikation zwischen (Teil-)Systemen unterstützt werden sollen bzw. müssen und bieten damit einen guten Startpunkt für die Arbeiten im Zuge dieses Zwischenstopps. Diese helfen auch dabei, entsprechenden Strategien für eine eventuell notwendige Mehrmandantenfähigkeit der Systeme zu entwickeln.
Die Berücksichtigung des CAP-Theorem, in Kombination mit den Architekturzielen, gibt die weitere Richtung zur Etablierung von Formaten, persistenten Speichern und (distributed) Caches vor.
Die weitere Verfeinerung hinsichtlich klarer Zuständigkeitsgrenzen und Datenhoheit kann von der Context Map abgeleitet werden. Auf Basis der Entscheidungen wie mit dem System interargiert wird, können ideal auf die konkrete Zielarchitektur abgestimmte Datenformate entworfen werden.
Der aufmerksamen Leser:in wird an dieser Stelle vermutlich aufgefallen sein, dass sämtliche Ergebnisse der bereits beschriebenen Zwischenstopps (Architect, Interact, Communicate) in diesen Zwischenstopp einfließen und maßgebliche Auswirkungen auf diesen haben. Da es sich bei den Zwischenstopps jedoch nicht um "Silos" handelt, werden diese zwar fokussiert durchgeführt, jedoch immer mit der Flexibilität Themen aus anderen Zwischenstopps mitzubearbeiten wenn sinnvoll und nötig.
Damit schließt sich der Kreis der eher Software-Architekturlastigen Zwischenstopps. Die nächsten Zwischenstopps zielen in die Richtung Delivery & Experience ab.
Tatsächlich ist es auch so, dass wir die gesamte Cloud Native App Journey oftmals in zwei Streams aufteilen bzw. anbieten. Das wäre zum einen der "Architecture & Design"-Stream mit Architect, Interact, Communicate und Exchange inkludiert und zum anderen der "Delivery & Experience"-Stream mit Protect, Deliver, Observe und Experience inkludiert.
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 😉