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 Service-Orientierten-Architektur (SOA) sollte sich dies Anfang des aktuellen Jahrtausends ändern. Ziel war es, Anwendungen in überschaubar große Services aufzuteilen, die sich dann neu zusammensetzen lassen (Build for Reuse). Nun starten Unternehmen wie Amazon, Netflix und Twitter die nächste Stufe moderner Architekturen: Microservices.
Foto: KPMG
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 Interface). 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 auch zu einer neuen Komplexität.
Verlieren BPMS an Bedeutung ...
Business-Process-Management-Systeme (BPMS) bzw. Workflow-/Process-Engines werden in SOA-Architekturen eingesetzt, um eine übergreifende Orchestrierung von Services zur Unterstützung eines Geschäftsprozesses zu erreichen. Kerngedanke von Microservices ist dagegen 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 müssen.
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 Microservices untereinander, was mehreren Grundprinzipien von Microservice-Architekturen entgegensteht.
... oder sind sie weiterhin sinnvoll?
BPM-Lösungen adressieren jedoch auch diverse Probleme, die sich insbesondere vor dem Hintergrund langlaufender Geschäftsprozesse ergeben. So ist es in großen Systemen beispielsweise kaum möglich eine Transparenz darüber zu schaffen, welche Microservices eine bestimmte Funktion bzw. einen bestimmten Geschäftsprozess ermöglichen. Automatisiert erstellbare Dead-Star-Diagramme zeigen zwar Aufrufe der Services untereinander, aber geben keinen Aufschluss über die Prozessketten. Dies erschwert u.a. auch die Kommunikation mit dem Fachbereich, wenn es um die Definition von Anforderungen geht.
Auch bei der Ausführung von Prozessen sind bei Microservice-Architekturen Herausforderungen zu beobachten. So ist der Status einer einzelnen Prozessinstanz (z.B. 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-zu-Punkt-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 vorhanden Geschäftsprozesse werden explizit dargestellt und damit für Entwickler und Fachbereich nachvollziehbar. Zusammenhängende Nachrichten können basierend auf standardisierten Sprachen (BPMN, Business Process Model and Notation, bzw. BPEL, Business Process Execution Language) 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 Microservice-Vorreiter wie beispielsweise 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 innerhalb 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 Legacy-Systemen 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.