Micro Services – die Insider-Perspektive. Teil 4:

„LIEBER LEICHT SEIN ALS SCHWER HABEN.“

Das Grundprinzip aller Micro Service-Architektur lautet: „Leicht und agil ist gut und effizient“. Es stand hinter allen Bemühungen um die Optimierung der in Teil 3 dieser Serie beschriebenen schlanken Choreografie-Lösungen. Und es erklärt, warum viele Micro Service-Pioniere fremdelten, als erstmals BPM-Engines zur Orchstrierung von Micro Service-Systemen herangezogen wurden: Zu schwergewichtig. Zu viel Initialaufwand. Zu mühsame Inbetriebnahme. Passt gar nicht zu Micro Services. Sagten sie damals. Mittlerweile haben sie ihre Meinung geändert. Mit guten Gründen.

Denn rasch erwiesen sich orchestrierte Systeme mit zentraler Steuerung als um nichts problematischer, komplexer und schwerfälliger als choreografierte Lösungen – im Gegenteil, Orchestratoren räumen buchstäblich mit den inhärenten Problemen von choreografierten Systemen auf:

Geschäftsprozesse verschwinden nicht mehr in abstrakten Codes, sondern können Parameter für Parameter in Echtzeit zentral überwacht und im BPMN-Kontext visuell dargestellt und modelliert werden. Logische Fehler werden auf einen Blick erkennbar. Timeouts und ähnliche Fehler können automatisiert verarbeitet werden. Visualisierung macht die Prozesse für alle Stakeholder verständlich. Kurz gesagt: Alles klar.

Der aktuelle State of the Art lautet deshalb: Choreographierte Systeme werden nur noch für einfache Standard-Prozesse eingesetzt, und selbst dabei ist zu bedenken, dass jeder neu hinzukommende, komplexere Prozess dem System und seinen Betreibern exponentiell wachsende Probleme bescheren würde.

Ausschließlich auf Choreografie zu setzen macht deshalb selten Sinn, umso weniger als es durchaus möglich ist, Choreographie und Orchestrierung in ein und demselben System zu mischen. Auch BPM-Engines müssen nicht zwingend als schwergewichtige, monolithische Zentralinstanzen eingesetzt werden. Im Gegenteil – es ist möglich und oft sinnvoll, abgeschlankte Engines direkt in einzelne Microservices zu integrieren. Beispielsweise könnte ein Payment-Service im Kontext eines Order-Services intern eine BPM-Engine verwenden, um den Payment-Prozess zu steuern.

Prominente Microservice-Vorreiter wie Netflix haben den Mehrwert solcher Orchestratoren für die Microservice-Architektur früh erkannt und dazu eigene, schlanke BPM-Engines entwickelt. Conductor ist ein gutes Beispiel. Auch auf dem freien Markt sind mittlerweile gleich mehrere leichtgewichtige BPM-Engines wie Camunda oder Zeebe erhältlich. Sie können als Teil eines Microservices embedded laufen und auch in der Cloud verwendet werden.

Die wachsenden Popularität solchen Lösungen spiegelt sich auch in veränderten Lizenzmodellen: Immer öfter wird nicht mehr nach Anzahl der Server oder CPUs, sondern nach Transaktionszahlen verrechnet.

Die Anatomie und Vorzüge einer solchen schlanken BPM-Engine werden wir im nächsten und letzten Teil unserer Blog-Serie betrachten.

Top