Microservices versus BPMS
Verlieren Business-Process-Management-Systeme (BPMS) in Zeiten populär werdender Microservice-Architekturen an Bedeutung? Vor allem Internet-Größen wie Amazon, Netflix und Twitter setzen auf Microservices, während etablierte Unternehmen sich häufig für BP
Verlieren Business-Process-Management-Systeme (BPMS) in Zeiten von Microservice-Architekturen an Bedeutung? Vor allem Internet-Größen wie Amazon, Netflix und Twitter setzen auf Microservices, während etablierte Unternehmen häufig BPMS verwenden.
In der Vergangenheit war es üblich, IT-Anwendungen nach ausgiebiger Konzeption als große, monolithische Blöcke zu entwickeln. Ein Problem dieser Anwendungsarchitekturen war, dass einmal entwickelte Funktionen nur schwer in anderen Anwendungen wiederverwertet werden konnten. Mit der Serviceorientierten Architektur (SOA) sollte sich dies Anfang des Jahrtausends ändern. Ziel war es, Anwendungen in überschaubar große Services aufzuteilen, die sich dann neu zusammensetzen lassen (Build for Reuse) sollten. Längst haben Unternehmen wie Amazon, Netflix und Twitter die nächste Stufe moderner Architekturen gestartet: Microservices.
Microservices vs. SOA
Microservice-Architekturen zielen vor allem auf eine hohe Änderungsgeschwindigkeit ab, um den dynamischen Anforderungen an aktuelle Anwendungen gerecht zu werden. Während bei SOA-Architekturen die hohe Abhängigkeit der Services voneinander oft ein Problem darstellte, ist Unabhängigkeit oberstes Ziel von Microservices-Architekturen (Build for Replacement). Um einen unabhängigen Lebenszyklus der Services sicherzustellen, gilt es stabile, versionierte Schnittstellen zu schaffen (zumeist asynchrone REST-APIs = REpresentational State Transfer Application Programming Interfaces). Durch eine hohe Fehlertoleranz und lokale Datenhaltung wird die Entkopplung weiter unterstützt und eine unabhängige Skalierung der einzelnen Services ermöglicht. In Summe verhelfen dezentrale Microservices so zu einer hohen Flexibilität und Geschwindigkeit. Gleichzeitig führen die feingranularen, sich ständig ändernden Services aber auch zu einer neuen Komplexität. Verlieren BPMS an Bedeutung ...
Business-Process-Management-Systeme beziehungsweise Workflow-/Process-Engines werden in SOA-Architekturen eingesetzt, um eine übergreifende Orchestrierung von Services zur Unterstützung eines Geschäftsprozesses zu erreichen. Dagegen ist der Kerngedanke von Microservices die freie Choreografie der Services untereinander statt einer übergreifenden Orchestrierung. Zentrale Architekturkomponenten wie BPMS stehen daher – zumindest auf den ersten Blick – im Gegensatz zum Architekturkonzept unabhängiger Microservices.
Ein zentrales BPMS könnte zum Flaschenhals werden und die Änderbarkeit der Anwendung einschränken, da große Teile der Anwendungslogik dort gebündelt vorliegen. Bei Änderungen muss daher jeweils das BPMS angepasst und getestet werden. Die lokale Datenhaltung in den Microservices kann in diesem Fall auch nicht mehr vollständig erhalten bleiben, da zumindest ein Teil der Daten im BPMS vorgehalten werden muss.
Im BPMS läuft zudem Fachlichkeit aus mehreren Bereichen zusammen, was die Komplexität weiter erhöht. Diese und weitere Aspekte führen letztendlich zu einer engeren Kopplung der Services untereinander. Das steht gleich mehreren Grundprinzipien von Microservice-Architekturen entgegen.
... oder sind sie weiterhin sinnvoll?
BPM-Lösungen gehen jedoch auch diverse Probleme an, die sich insbesondere vor dem Hintergrund langlaufender Geschäftsprozesse ergeben. So ist es in großen Systemen beispielsweise kaum möglich, Transparenz darüber zu schaffen, welche Microservices eine bestimmte Funktion beziehungsweise einen bestimmten Geschäftsprozess ermöglichen. Automatisiert erstellbare Dead-Star-Diagramme zeigen zwar Aufrufe der Services untereinander, geben
aber keinen Aufschluss über die Prozessketten. Dies erschwert unter anderem auch die Kommunikation mit dem Fachbereich, wenn es um die Definition von Anforderungen geht. Auch bei der Ausführung von Prozessen sehen sich Anwender in Microservice-Architekturen mit gewissen Herausforderungen konfrontiert. So ist der Status einer einzelnen Prozessinstanz (zum Beispiel der Zustand einer Bestellung) nicht ohne Weiteres abrufbar. Dies ist darauf zurückzuführen, dass die Prozessinstanz Punkt-zu-Punkt zwischen den Microservices „weitergegeben“wird.
Eine Statusabfrage müsste daher an jeden Service gestellt werden. Genau diese Punkt-zuPunkt-Verbindungen erschweren auch die Wartbarkeit der Prozesse und machen die Steuerung der Reihenfolge von Serviceaufrufen komplex. Soll nun beispielsweise eine bereits aufgegebene Bestellung storniert werden, sind die Microservices mit zwei widersprüchlichen Nachrichten konfrontiert.
Auch Netflix setzt BPMS ein
Ein BPMS kann hier (gegebenenfalls in Kombination mit einem Enterprise-Service-Bus) Abhilfe schaffen. Die implizit in den Microservices vorhandenen Geschäftsprozesse werden explizit dargestellt und damit für Entwickler und Fachbereich nachvollziehbar. Zusammenhängende Nachrichten können basierend auf standardisierten Sprachen (Business Process Model and Notation, BPMN, beziehungsweise Business Process Execution Language, BPEL) koordiniert werden, und der Status einer jeden Prozessinstanz wird transparent.
Die Integration vorhandener Legacy-Systeme, die über keine REST-Schnittstelle verfügen, wird ebenfalls vereinfacht. Auch MicroserviceVorreiter wie Netflix haben diese Vorteile erkannt und ergänzen ihre Microservice-Architektur daher durch eine BPMS-Komponente für langlaufende Prozesse (Netflix Conductor).
Microservices und BPMS können sich ergänzen
Um die eingangs aufgeführten Probleme einer zentralen Steuerungsinstanz zu vermeiden und dennoch die möglichen Vorteile zu realisieren, sind auch Kompromisse zwischen beiden Extremen (volle Steuerung durch BPMS vs. keine zentrale Steuerung) denkbar. So könnte ein übergreifendes BPMS den Status der Prozesse überwachen, ohne die direkte Kommunikation zwischen den Services zu ersetzen. In einem solchen Szenario würden wichtige Prozessabschnitte durch Events vom BPMS an die Microservices gestartet werden. Die eigentliche Durchführung erfolgt dann eigenständig inner- halb der Microservice-Schicht. Erst nach Abschluss dessen kommt das BPMS wieder zum Einsatz, um den weiteren Prozessverlauf zu steuern.
Eine IT der zwei Geschwindigkeiten entsteht
Sollten Prozessschritte durch Legacy-IT ausgeführt werden, könnte das BPMS dies ebenfalls koordinieren und so eine Brücke zwischen Legacy- und Microservice-Schicht schaffen. Eine so strukturierte Architektur würde letztendlich aus schnellen Microservices, langsamen LegacySystemen und einem BPMS als Integrator bestehen – eine IT der zwei Geschwindigkeiten entsteht.
Das Beispiel verdeutlicht, dass in der Realität selten Architekturen in ihrer Reinform zu finden sein werden. Jedes Unternehmen muss hier individuell eine für sich geeignete Lösung schaffen. Während die Steuerung durch BPMS tendenziell die Änderbarkeit des Gesamtsystems im Vergleich zu reinen Microservices reduziert, entsteht andererseits eine zentrale Kontrolle und einfachere Integration von Legacy-IT. Für etablierte Unternehmen wird diese Kontrolle oft wichtiger sein als tägliche Änderungen. Insgesamt werden BPM-Lösungen also auch in Microservice-Architekturen eine Daseinsberechtigung haben.