Wie ein Service Orchestrator komplexe Geschäftsprozesse in Microservices umsetzt

In modernen Softwarearchitekturen, besonders in Microservices, ist es häufig erforderlich, komplexe Geschäftsprozesse zu orchestrieren, die mehrere Microservices miteinander verbinden. Ein häufiger Fehler bei der Gestaltung von Microservices besteht darin, eine zu enge Geschäftslogik in einem einzelnen Microservice zu integrieren. Diese enge Fokussierung kann dazu führen, dass mehrere Microservices zur Ausführung eines komplexen Vorgangs zusammenarbeiten müssen, was die Komplexität erhöht und den Wartungsaufwand steigert. Stattdessen ist es empfehlenswert, Microservices so zu gestalten, dass sie eine breitere Geschäftslogik abdecken, die in der Lage ist, komplexe Aufgaben im jeweiligen Domänenbereich zu bewältigen. Ein solcher Ansatz kann durch den Einsatz eines Service Orchestrators erreicht werden.

Ein Service Orchestrator übernimmt die Rolle eines Geschäftsprozesses, der komplexe Aufgaben innerhalb eines Business Process Management (BPM)-Systems implementiert. Der Orchestrator führt jede einzelne Aufgabe durch und ruft dafür entsprechende Microservices auf, die jeweils ihre eigenen Datenbanken oder Backend-Services nutzen, um die erforderlichen Aufgaben zu erledigen. Dabei kann der Geschäftsprozess als Service-API nach außen exponiert werden, entweder direkt durch den Orchestrator oder durch einen speziellen Adapter-Microservice, der die Orchestrierung des Geschäftsprozesses vorstellt.

Ein besonders wichtiger Aspekt eines Service Orchestrators ist die Möglichkeit, bereits abgeschlossene Schritte durch "kompensierende Transaktionen" rückgängig zu machen. Diese Art von Transaktion führt die entgegengesetzte Aktion zu einer vorherigen Transaktion aus und wird häufig innerhalb des gleichen Microservices implementiert. Der Service Orchestrator funktioniert in diesem Fall wie eine Orchestrierungseinheit, die sicherstellt, dass jeder Schritt nur einmal erfolgreich ausgeführt wird.

Ein weiterer Vorteil eines Service Orchestrators besteht darin, dass er es ermöglicht, komplexe Aufgaben durch die Kombination von anderen, einfacheren Aufgaben zu realisieren. So kann ein Orchestrator in einem E-Commerce-System eine Aufgabe wie den Checkout-Prozess orchestrieren, indem er Microservices für die Verwaltung von Bestellungen, Produktinformationen, Lagerbeständen und Zahlungen miteinander verbindet. Diese Aufgaben können nicht einfach in einem einzigen Microservice zusammengefasst werden, da dies zu einer schlechten Microservice-Architektur führen würde, in der einzelne Services zu komplex und wenig wiederverwendbar sind.

Die Wahl zwischen verschiedenen Orchestrierungsstrategien hängt oft von der spezifischen Situation und den Anforderungen des Systems ab. Manchmal kann es sinnvoll sein, zunächst mit einer einfachen Orchestrierung innerhalb eines einzelnen Microservices zu beginnen und später, während der Refaktorisierung, auf eine BPM-basierte Lösung umzusteigen. Entscheidend für diese Entscheidung sind Faktoren wie die Komplexität der Aufgaben, die zu orchestrieren sind, und die Anforderungen an Skalierbarkeit und Fehlerbehandlung.

Die Gestaltung eines Service Orchestrators ist komplexer als die traditionelle IT-Programmierung, bei der mehrere Aufgaben sequenziell abgearbeitet werden. Während einfache Microservices oft in einer statischen Umgebung mit klar definierten Transaktionen ausgeführt werden, müssen Service Orchestrators häufig in einer dynamischen, skalierbaren Cloud-Umgebung arbeiten, die mit einer Vielzahl von Backend-Datenquellen und Diensten kommuniziert. Dies erfordert eine sorgfältige Planung der Datenbanken und deren Interaktionen, insbesondere wenn mehrere Datenquellen beteiligt sind. Einfache Microservices mit nur Lesezugriff auf Daten können noch relativ einfach orchestriert werden, aber sobald schreibende Transaktionen ins Spiel kommen, wird die Orchestrierung deutlich komplexer und erfordert den Einsatz eines BPM-Engines.

Die Verwendung eines Service Orchestrators bietet sich insbesondere in Systemen an, die kurze, komplexe Aufgaben in einer verteilten Umgebung ausführen müssen. In diesen Szenarien erweist sich der Orchestrator als ein unverzichtbares Werkzeug, um die Verteilung und Koordination der Aufgaben effizient zu gestalten und eine robuste Fehlerbehandlung zu gewährleisten. Im Vergleich dazu stehen andere Architekturen wie Event-Driven oder choreografierte Systeme, die dynamischere Reaktionen auf Ereignisse ermöglichen, jedoch weniger vorhersagbar sind.

Beispiel für einen Service Orchestrator im E-Commerce:

Ein praktisches Beispiel für den Einsatz eines Service Orchestrators findet sich im E-Commerce-Bereich, wenn es darum geht, die Verfügbarkeit eines Produkts anzuzeigen. Nehmen wir an, ein Online-Shop möchte nicht nur Produktinformationen anzeigen, sondern auch den Lagerbestand abfragen. Hierfür gibt es zwei Microservices: einen für das Produktkatalog-Management und einen weiteren für das Lagerbestandsmanagement. Der Service Orchestrator stellt sicher, dass beide Microservices miteinander kommunizieren, um die notwendigen Daten zu kombinieren und dem Kunden die vollständige Produktinformation anzuzeigen.

Der Orchestrator in diesem Fall würde also die Aufgaben der Produktdarstellung und der Lagerbestandsabfrage kombinieren. Während der Microservice für den Produktkatalog nur Produktdetails liefert, fragt der Adapter-Microservice den Lagerbestand ab und gibt diese Informationen weiter. Der Service Orchestrator stellt sicher, dass der Kunde eine vollständige Produktinformation erhält, ohne dass alle Funktionen in einem einzigen, überladenen Microservice implementiert werden müssen.

Die Integration eines Service Orchestrators in komplexe Geschäftsprozesse ist somit eine wertvolle Strategie, um Flexibilität, Fehlerresistenz und eine saubere Trennung der Verantwortlichkeiten zu gewährleisten.

Wie haben sich Computernetzwerke und Serverarchitekturen entwickelt?

Im Zuge der fortschreitenden Digitalisierung und der Entwicklung von Netzwerktechnologien haben sich auch die Architekturen von Computern und Anwendungen erheblich verändert. In den frühen Tagen der Personal Computer (PC)-Nutzung waren Anwendungen isolierte Programme, die lokal auf dem Desktop-Rechner des Nutzers liefen. Diese monolithischen Desktop-Anwendungen erinnerten in ihrer Struktur an Mainframe-Anwendungen, wenn auch vereinfacht. Sie waren in der Regel auf einen einzigen Nutzer beschränkt, und obwohl mehrere Nutzer im selben Büro möglicherweise dieselbe Software verwendeten, hatte jeder Nutzer eine eigene Kopie der Anwendung, die lokal auf seinem Computer lief.

Diese Entwicklung führte zu einer Umstrukturierung der Architektur, bei der zunehmend Server eine zentrale Rolle übernahmen. Statt dass die Anwendungen weiterhin auf den lokalen PCs der Mitarbeiter liefen, wurden sie auf zentralen Anwendungsservern betrieben. Diese Entwicklung war der Ursprung des Client-Server-Modells. Bei dieser Architektur wurde die Programmlogik und die Daten zentral auf dem Server verwaltet, während der Client – also der Desktop-PC des Nutzers – die Benutzerschnittstelle und personalisierte Logik übernahm.

Der Vorteil dieses Modells war, dass mehrere Mitarbeiter gleichzeitig auf dieselbe Anwendung zugreifen und Daten in Echtzeit bearbeiten konnten, ohne dass die Gefahr bestand, sich gegenseitig zu überschreiben. Dies führte zu einer erheblichen Verbesserung in der Zusammenarbeit und der Effizienz. Zudem konnten die Server auch komplexere Berechnungen durchführen, während die Desktop-Computer der Nutzer weiterhin eine gewisse Rechenkapazität behielten.

In den frühen 2000er Jahren verlagerten sich diese zentralisierten Architekturen weiter in die Cloud. Der Unterschied zur traditionellen Serverstruktur lag vor allem in der Virtualisierung der Infrastruktur. Während frühere Anwendungsserver auf spezialisierte Server beschränkt waren, die jeweils eine bestimmte Technologie oder Programmiersprache unterstützten, war die Cloud in der Lage, eine breitere Palette von Programmen zu hosten, die in virtuellen Maschinen liefen. Diese virtuellen Maschinen boten nicht nur virtualisierte Rechenkapazitäten, sondern auch Speicher und Netzwerke, was die Flexibilität der Anwendungen erhöhte.

Ein bedeutender Vorteil der Cloud war die Möglichkeit, Anwendungen als „Software-as-a-Service“ (SaaS) bereitzustellen. Das bedeutet, dass Unternehmen und Entwickler keine eigenen Server mehr betreiben mussten, sondern die benötigten Anwendungen und Dienste über die Cloud bezogen. Dies führte zu einer noch stärkeren Zentralisierung und einer Vereinfachung der IT-Infrastruktur, da Entwickler nun auf eine Vielzahl von Dienstleistungen zugreifen konnten, ohne sich um die Verwaltung der zugrundeliegenden Infrastruktur kümmern zu müssen.

Ein weiterer Fortschritt war die Verwendung von Webbrowsern als universelle Plattform für den Zugriff auf Anwendungen. Während in der Vergangenheit jeder Nutzer eine separate Anwendung installieren musste, um auf die Serveranwendungen zugreifen zu können, genügte es nun, einfach einen Webbrowser zu verwenden. Dies führte zu einer breiten Akzeptanz von Cloud-Anwendungen, da Nutzer nun von fast jedem Gerät – sei es ein Desktop, ein Laptop oder sogar ein Mobilgerät – auf ihre Anwendungen zugreifen konnten.

Heute sind Cloud-native Anwendungen der Standard. Diese Anwendungen wurden speziell für die Nutzung in der Cloud entwickelt und optimiert. Sie nutzen die Vorteile der Cloud-Infrastruktur voll aus, um skalierbare und flexible Lösungen anzubieten. Bei Cloud-native Anwendungen werden die Geschäftslogik und alle gemeinsamen Dienste wie Datenbanken, Messaging-Systeme oder Authentifizierungsdienste über Backend-Services in der Cloud bereitgestellt, sodass die Server-Anwendungen sich auf die spezifische Logik konzentrieren können.

Der Übergang von traditionellen Desktop-Anwendungen zu zentralisierten Client-Server-Architekturen und schließlich zu Cloud-nativen Anwendungen zeigt eine klare Tendenz zur Zentralisierung und Virtualisierung von IT-Ressourcen. Dabei ist es wichtig zu erkennen, dass diese Entwicklungen nicht nur technologische Fortschritte, sondern auch tiefgreifende Veränderungen in der Art und Weise sind, wie Unternehmen ihre IT-Infrastrukturen und Anwendungen verwalten. Die Cloud bietet nicht nur mehr Flexibilität und Skalierbarkeit, sondern auch neue Möglichkeiten der Zusammenarbeit und des Zugriffs auf Anwendungen von nahezu jedem Ort der Welt aus.

Wie Ereignisbenachrichtigungen und Event-Backbones in Großunternehmen verwaltet werden

In modernen IT-Architekturen, insbesondere bei großen Unternehmen oder komplexen Systemen, ist eine präzise und zuverlässige Ereignisübertragung von entscheidender Bedeutung. Dies ist besonders im Zusammenhang mit Microservices und der Verarbeitung von Ereignissen über Event-Backbones relevant. Die Verwaltung von Nachrichten und Benachrichtigungen, die über verschiedene Systeme hinweg übertragen werden, erfolgt in der Regel in einer Art asynchronem Messaging-System. Dieses System ist dafür verantwortlich, die Konsistenz und Verlässlichkeit der Übertragung zu gewährleisten, wobei bestimmte Designprinzipien, wie die Maximierung der Konsistenz auf Kosten der Verfügbarkeit, berücksichtigt werden.

In einem sehr großen System oder Unternehmen besteht nicht nur eine einzige Domain, sondern häufig mehrere miteinander interagierende Domains. Dies wird besonders deutlich, wenn man sich die verschiedenen Funktionsbereiche eines Unternehmens vorstellt. Nehmen wir als Beispiel ein Unternehmen, das Software-as-a-Service (SaaS) anbietet. Hier gibt es verschiedene Domänen wie den Verkaufsprozess, die Abrechnung und die Personalprozesse, die jeweils ihre eigenen komplexen Anforderungen an die Verwaltung von Daten und Nachrichten stellen. So erfordert der Verkaufsprozess die Verwaltung von Leads, Verträgen und deren Verlängerungen, während der Abrechnungsprozess sicherstellen muss, dass die verschiedenen Rechnungsarten und Rabatte korrekt abgebildet werden. Diese verschiedenen Systeme müssen nicht nur innerhalb ihrer eigenen Domänen kommunizieren, sondern auch über Domain-Grenzen hinweg, was eine besondere Herausforderung darstellt.

Diese Art der Organisation erfordert den Aufbau einer Art „Brücke“ zwischen den verschiedenen Event-Backbones. Eine solche Brücke fungiert als Vermittler, der Ereignisse von einem Backbone empfängt und sie an einen anderen Backbone weitergibt. In großen Unternehmen gibt es deshalb oft eine übergeordnete Struktur, die als Enterprise Backbone bezeichnet wird und verschiedene Event-Backbones miteinander verbindet. Diese Art von Architektur ermöglicht eine koordinierte Kommunikation zwischen den Abteilungen, auch wenn diese unterschiedliche Technologien verwenden.

Die Gestaltung solcher Systeme ist nicht einfach, da es notwendig ist, zu entscheiden, welche Ereignisse über die verschiedenen Backbones hinweg kommuniziert werden sollen. Es ist entscheidend, die Menge der Ereignisse zu begrenzen, die über Domains hinweg geteilt werden, um Überlastung zu vermeiden und sicherzustellen, dass nur wirklich relevante Daten ausgetauscht werden. Ein weiterer Aspekt ist die Wahl des richtigen Event-Management-Systems, das je nach Unternehmensgröße und Technologieanforderungen variieren kann. Für die Abrechnung könnte dies beispielsweise ein SAP Event Management-System sein, während für Marketing oder spezielle digitale Kampagnen eine Lösung wie Twilio’s Segment besser geeignet sein könnte.

Wichtig ist, dass bei der Kommunikation zwischen den verschiedenen Event-Backbones nicht jeder Vorgang eines Systems an ein anderes System weitergegeben werden muss. Ein Ereignis, das für den Verkaufsprozess von Interesse ist, muss nicht zwangsläufig auch für die Personalabteilung oder die Abrechnung relevant sein. Diese Trennung von interessanten Ereignissen ist eine der größten Herausforderungen bei der Gestaltung solcher Systeme. Um eine saubere Architektur zu gewährleisten, sollten Unternehmen darauf achten, dass nur relevante Informationen zwischen den verschiedenen Abteilungen und Systemen geteilt werden.

In einem größeren Kontext betrachtet, ermöglicht die Kombination von Event-Backbones und einer übergreifenden Event-API eine hochgradig skalierbare, reaktive und modulare Systemstruktur. Diese Struktur ist für die moderne Unternehmensarchitektur unerlässlich, da sie eine hohe Flexibilität und Anpassungsfähigkeit an sich ändernde Geschäftsanforderungen bietet. Sie stellt sicher, dass das Unternehmen in der Lage ist, sowohl lokal als auch in einer breiten, unternehmensweiten Perspektive zu agieren und auf Ereignisse schnell und effizient zu reagieren.