Microservices mit Choreographie oder doch mit Orchestration

Microservices sind so schon kompliziert und denn kommt noch dazu man muss für eine der Pattern benutzen und es verstehen bevor man es anwendet. Es gibt viele Patterns für Microservices. Hier werde ich erstmals nur zwei Prominente Varianten vorstellen und meine Meinungen dazu geben.

Weil wir weg von Monolith sind wo ganze System als eine agiert und alles mit einander verbunden ist, müssen wir hier was ganz besonderes achten. Was ist was wir so schlecht in Microservices bewachen kann. Es geht um Zustand. Zustand ist der Knackpunkt was wegen wir unterschiedliche varianten von Microservices benutzen. Weil jetzt jeder Service eigene Datenbank hat und es verteilt ist wir können schwer sehen was aktuell in unsere Systemlandschaft los ist. Ohne besondere Hilfe können wir schwer aktuelle zustand eine Bestellung sehen die in unser Landschaft von 10-20 Microservices unterwegs ist. Diese besondere hilfe werde ich später vorstellen erstmal nur die Probleme die dieser Patterns versuchen zu lösen.

Ich muss vorher schon sagen ich habe diese Pattern gesucht weil die am Markt meisten verbreitert sind. Es gibt andere Patterns auch die noch exotischer sind als diese aber die bringen eigene Vorteile mit sich.  Die Patterns entscheiden auch unsere Architektur und weitere Entscheidungen die wir während der Projekt und danach mittragen müssen daher soll der Entscheidung richtige überlegt sein muss.

Ich gehe erstmal auf Orchestration Pattern wo wir eine Zentrale Master haben der die ganze Musik Bande (Microservices) Orchestriert. Er gibt vor was als nächste zu tun ist. In Microservices Bereich zbs in E-Commerce könnte hier Order Service eine Beispiel sein. Diese Services gibt andere Services zbs. Warenbestand Service, Zahlung Service was zu tun ist. Diese wird denn der Zustand der Microservices halten. Es gibt also eine Zentrale stelle die alles kontrolliert. Diese ist auch gleichzeitig eine Segen und curse für unsere Landschaft. Denn wenn diese Orchestrator tot ist kann die weitere Services gar nicht arbeiten. Wir haben der Zustand von Transaktionen die in unsere Micro Services unterwegs sind auf eine stelle aber wir haben uns dadurch eine Single Point of Failure gebaut.

Dagegen kämpft der zweiter Variante nämlich Choreographie Pattern. Hier sind alle von einander losgelost tanzen mit Harmonie mit einander. Jeder weiß was zu tun ist und keiner sagt wo es lang geht. Jede Service reagiert auf bestimmter Events und tut nur eigene Arbeit und funktioniert mit “fire and forget” prinzip. Diese Ansatz hat eine Vorteil dass jeder Service komplett unabhängig von andere ist und wir haben keine Single point of failure. Wenn eine teil tot ist funktioniert trotzdem der andere. Aber hier haben wir eine Problem dass wir keiner haben der zustand kontrolliert. Also hier können wir der Zustand nicht einfach sehen da es in unterschiedliche Services verteilt ist. Wir müssen hier mit mühe kontrollieren um aktuelle zustand der Services zu sehen. Außerdem wenn wir Workflow andern wollen müssen wir alle Services anpassen. Diese ist eine Stabiler Ansatz aber verbunden mit zusätzlich Arbeit. Das bedeutet  wir müssen irgendwie unsere Zustand kontrollieren und immer zusätzlich Arbeit leisten wenn wir unsere Workflow andern.

Weitere Aspekte die wir wissen soll sind wie folgt.

In beide fälle müssten wir verschiedene Tools benutzen um Monitoring zu bewerkstelligen. Da es einzelne Microservices nur eigene Logs schreiben und keine gemeinsamer platz für ausgaben haben wichtig ist dass wir externe Hilfe holen diese Logs zu Korrelieren. Es soll auch Tracing in Betracht gezogen werden um Transaktionen Abläufe in Entwicklung als auch in Produktion zu kontrollieren.

Fachlich Monitoring ist auch eine wichtiger Aspekt der nicht runtergeredet werden soll. Fachlich soll in der lage sein Kunden anfragen einfach zu beantworten und da kommt wieder unser Zustand in speil. In meisten fälle wir benötigen eine State Maschine. Es gibt viele variante aber was mir so meistens gefällt ist Camunda. Es kann zustand der Services an eine stelle bringen und somit fachliche Leute Kunden anfragen wegen zustand der Transaktion geben. Mithilfe von Camunda können wir beide Patterns sehr gut die Nachteile glatt bügeln.

Mehr von Camunda in eine andere folge.