Micro Services – die Insider-Perspektive. Teil 3:

„TANZEN ODER SPIELEN – DAS IST HIER DIE FRAGE?“

Willkommen bei Teil 3 unserer Blog-Reihe über Micro-Services – einen jungen Ansatz der IT-Architektur, der statt auf monolithische System-Dinosaurier auf hoch agile Bienenschwärme von kompakten, autonomen Services setzt. Die Kunst besteht dabei darin, die einzelnen Services als sinnvolles, effizientes, agiles Ganzes zu organisieren.

Denn kein Auto kann auf einem einzigen Rad fahren und kein Geschäftsprozess besteht aus einem einzigen Service: Microservices wie Billing, Payment und Shipping müssen kollaborieren, damit ein Prozess, und daraus ein Mehrwert für das Unternehmen, entsteht.

Gehen wir daran, solche Kollaborationen zu organisieren, dann steht eine Grundsatzentscheidung an: Orchestrieren – oder choreographieren?

Choreographierte Micro Services verhalten sich wie Tanzpaare in einem Ballsaal, die, ihren eigenen Routinen folgend, aufeinander reagieren und umeinander herum navigieren, ohne dass eine zentrale Steuerungsinstanz eingreift. Denn statt andere Services direkt aufzurufen, schreiben choreographierte Micro Services relevante Events in einen Message-Bus, z. B. Apache Kafka, den andere Services auf bestimmte, für sie relevante Events abhören. Publiziert z.B. ein Customer-Service bei der Neuanlage eines Kundenprofils den Event ‚Customer created‘, reagiert das Loyalty-Service mit den entsprechenden nächsten Prozessschritten. Wir nennen das asynchrone, event-basierte Kommunikation.

Die dabei Schritt für Schritt entstehende Eventkette bildet den gesamten Geschäftsprozess ab. Ein zentraler Steuerungsapparat ist überflüssig und die Kopplung zwischen den einzelnen Services ist so lose wie überhaupt nur möglich – ein Idealzustand in der Micro Service-Architektur.

Warum also nicht alle Micro Services orchestrieren? Weil jeder Idealzustand seinen Preis hat. Verwender orchestrierter Services entrichten ihn erstens in Form erhöhter Komplexität infolge asynchroner Kommunikation, zweitens durch totale Abstraktion, die Geschäftsprozesse nur mehr implizit in Form von Events abbildet bzw. im Code verbirgt, und drittens durch erhöhten Aufwand beim Monitoring des Gesamtprozesses: Choreografierte Systeme geben nicht von sich aus Auskunft, wie viele Prozesse derzeit laufen, wie viele Prozesse Fehlermeldungen produzierten usw.: Ein solches Monitoring müsste über kostspielige Custom-Lösungen eingerichtet werden.

Darüber hinaus lösen choreographierte Systeme das Versprechen der totalen Autonomie des einzelnen Services nur bedingt ein: Durch den Nachrichteninput und -output der Services entsteht eine indirekte Kopplung, die bei der Implementation neuer Anforderungen die Anpassung mehrerer Services erfordert – im eklatanten Widerspruch zur reinen Microservice-Lehre.

Lösen lässt sich dieses Manko durch eine Event-Command-Transformation, aber diese läge nicht im Verantwortungsbereich der beteiligten Services. Vielmehr müsste ein separates Service für diese Aufgabe erstellt werden, etwa durch Einsatz einer BPM-Engine, was aber wiederum den ersten Schritt zur zentralen Orchestrierung bedeuten würde.

Angesichts solcher Komplikationen wird verständlich, warum orchestrierte Micro Service-Systeme immer populär werden: Im Gegensatz zu choreographierten Architekturen sind sie mit einer zentralen Steuerstelle ausgerüstet. Diese lenkt den Gesamtflow, nicht unähnlich einem Dirigenten, der die Musiker eines Orchesters synchronisiert. Als Kommunikationsschiene zwischen Steuerstelle und Services wird häufig REST eingesetzt. Als zentraler Orchestrator eignen sich speziell leichtgewichtige BPM-Engines wie Camunda, Zeebe oder Conductor.

Warum solche Konstruktionen anfänglich mit Vorurteilen zu kämpfen hatten, mittlerweile aber immer öfter die beliebten Choreografie-Lösungen überholen, erfahren Sie in Teil 4 unserer Blog-Serie.

Top