Die Herausforderungen einer Event-driven Architecture Ereignisgesteuerte Apps sind nur so gut wie der Event-Broker

Ob eine Event-driven Architecture, kurz EDA, die gewünschten Ergebnisse liefert, hängt oft von der Wahl des Event-Brokers ab. Wie die Lösungen sich unterscheiden und für welche Aufgaben und Anwendungsfälle die einen Event-Broker besser geeignet sind als andere, zeigt dieser Gastbeitrag.

Als Software-Designmuster erlaubt eine ereignisgesteuerte Architektur die automatisierte Echtzeitkommunikation zwischen verschiedenen Anwendungen über einen Event-Broker. Dieser Ansatz setzt sich zunehmend in Unternehmen durch, die zeitkritische Anwendungen, Geschäftsprozesse und Erkenntnisse (Advanced Analytics, Machine Learning, Künstliche Intelligenz) in großem Umfang nutzen wollen.

Die Implementierung von EDA-Plattformen ist in vollem Gange. Acht von zehn IT-Führungskräften gaben in einem von Solace gesponsortem IDC Infobrief an, dass ihre Unternehmen EDA in den folgenden 24 Monaten für zwei bis drei neue Anwendungsfälle einsetzen wollen. Die Einführung von EDA geht Hand in Hand mit der digitalen Reife. 47 Prozent der Befragten bezeichnen ihre EDA-Entwicklung entweder als ausgereift („zentralisiert“) oder als „fortgeschritten“.

Dabei ist der Vormarsch von EDA branchenunabhängig. Untersuchungen zeigen, dass immer mehr Unternehmen in allen Branchen – Einzelhandel, Finanzdienstleistungen, Luftfahrt, Fertigung, Transport und Logistik – die Notwendigkeit erkennen, dieses Modell der Anwendungskonnektivität zu übernehmen, um moderne Anwendungsfälle wie Click-and-Collect, vorbeugende Wartung von Maschinen, Digitale Zwillinge etc. effizient zu ermöglichen.

Das Herzstück der EDA-Transformation ist der Event-Broker, eine Middleware-Software, die Ereignisse und andere Daten zwischen verschiedenen Anwendungen, Systemen und Geräten weiterleitet. Mit der zunehmenden Verbreitung und Nutzung von EDA ist auch der Markt für Event-Broker gewachsen, sodass heute eine große Auswahl an Brokern zur Verfügung steht. Die Fähigkeiten der Event-Broker können jedoch sehr unterschiedlich sein. Softwarearchitekten und Anwendungsteams sollten deshalb ihre Bewertungskriterien sorgfältig definieren.

Die Wahl des richtigen Brokers kann über den Erfolg einer Strategie zur Integration von Echtzeitanwendungen entscheiden. Er ermöglicht die zuverlässige Übertragung von Ereignissen zwischen den verschiedenen Komponenten eines Systems und fungiert als Vermittler zwischen Publishern und Subscribern. Der Broker ist der Eckpfeiler der ereignisgesteuerten Architektur. Alle ereignisgesteuerten Anwendungen verwenden eine Form von Event-Broker, um Informationen zu senden und zu empfangen.

Der erste und entscheidende Schritt besteht für IT-Verantwortliche nicht mehr darin, zu entscheiden, ob sie EDA einsetzen sollen, sondern welchen Event-Broker sie wählen, um ihre EDA zu unterstützen bzw. welchen Broker sie für welche Anwendungsfälle einsetzen wollen. Denn häufig wird ein Unternehmen feststellen, dass es mehr als einen Broker-Typ benötigt, da nicht alle Broker für alle Anwendungsfälle geeignet sind.

Analysten beteiligen sich an der Debatte, darunter David Mooter von Forrester, der kürzlich die Wahl zwischen einem „Log-Stream-Broker“ und einem „Smart Broker“ erläuterte. Ein Log-Stream-Broker kann einen hohen Datendurchsatz unterstützen, ein gewisses Maß an Komplexität tolerieren und Nachrichten wiedergeben, wenn er mit Echtzeitanalysen und Event-Sourcing kombiniert wird. Im Gegensatz dazu kann ein Smart Broker komplexes Nachrichten-Routing, granulare Kontrolle der Nachrichtenfilterung, globale Auftragsgarantien und transaktionale Commits sowie viele andere Funktionen unterstützen.

Anwendungsfälle bestimmen die Wahl – analytisch oder operativ

Laut Mooter ermöglichen Event-Broker es den Unternehmen, ihre Anwendungen als eine Sammlung von zusammensetzbaren Diensten aufzubauen, die von Natur aus entkoppelt sind. Das bietet die Vorteile von Agilität, Skalierbarkeit und Ausfallsicherheit. Je nach Anwendungsfall sei es aber entscheidend, ob man sich für einen Log-Stream-Broker oder einen Smart Broker entscheide.

Das beste Beispiel für einen Log-Stream-Broker ist Apache Kafka. In den letzten Jahren hat Apache Kafka die Welt des Daten-Streamings im Sturm erobert, da es für seinen definierten Verwendungszweck sehr gut geeignet ist: die Aggregation riesiger Mengen von „Log“-Daten und das Streaming dieser Daten zu Analyse-Engines und Big-Data-Repositories.

Nicht alle Event-Broker sind gleichermaßen geeignet

Leider hat die Popularität und Verbreitung von Kafka viele Entwickler dazu verleitet, Kafka auch für Anwendungsfälle zu nutzen, für die es nicht ideal geeignet ist – nämlich für operative „Run-the-Business“-Szenarien, die oft eine Kombination von Anwendungen, Systemen und Geräten umfassen und auf bestimmte Ereignisströme zugreifen müssen, um effizient zu arbeiten.

Log-basierte Broker verwenden starre, flache Topic-Strukturen, um die übertragenen Daten zu beschreiben. Das bedeutet, dass die Anwendungen alle Daten filtern müssen, die übertragen werden. Und das kann sie schnell überfordern, da sie Ereignisse, die sie gar nicht benötigen, konsumieren, filtern und verwerfen müssen, was die Kosten und die Komplexität erhöht, ganz zu schweigen von Sicherheitsbedenken.

Mit zunehmender Vernetzung der Unternehmen muss der Broker intelligenter werden

Auf der anderen Seite übernehmen „intelligente“ Broker einen großen Teil des Denkens, Filterns und Weiterleitens, insbesondere wenn Unternehmen daran arbeiten, die verschiedenen Informationstechnologien (IT) und Betriebstechnologien (Operational Technologies, OT) stärker zu integrieren, zu vernetzen und in Echtzeit zu nutzen.

Diese Broker verfügen über reichhaltige, flexible Topic-Hierarchien, die es Anwendungen ermöglichen, auf einfache Weise die spezifischen Teilmengen von Daten, an denen sie interessiert sind, zu veröffentlichen und zu abonnieren. Aus der Perspektive des Event-Streamings unterstützen Smart Broker eine breite Palette von Nachrichtenaustauschmustern, die über Publish/Subscribe hinausgehen, wie Request/Response, Streaming und Replay, sowie verschiedene Servicequalitäten wie Best Effort und garantierte Zustellung.

Damit sind Smart Broker ideal für operative Anwendungsfälle, in denen sie als „digitales Nervensystem“ eines verteilten Unternehmens fungieren. Smart Broker gehen über die reine Analyse hinaus. Stellen wir uns eine globale Bank vor, die täglich mehr als 150 Milliarden Ereignisse zwischen Handelsplattformen mit geringer Latenz und Marktdatenzentren an verschiedenen Standorten auf der ganzen Welt austauscht. Kurse können in New York veröffentlicht und in London in kürzester Zeit abgerufen werden, so dass Aufträge schnell auf der Grundlage der aktuellsten Informationen erteilt werden können.

So finden Unternehmen den passenden Smart Broker

Die Entscheidung liegt auf der Hand: Wenn ein Unternehmen operative „Run-the-Business“-Anwendungen und Anwendungsfälle über ein verteiltes Unternehmen hinweg adressieren will, benötigt es einen intelligenten Broker, der drei entscheidende Eigenschaften aufweist:

1. Feinmaschiges Routen und Filtern

In komplexen Geschäftsprozessen müssen Ereignisse intelligent gefiltert und weitergeleitet werden, damit sie den richtigen Personen zur richtigen Zeit zur Verfügung stehen und nicht nur massenhaft serviert werden. Ein intelligenter Event-Broker ermöglicht es den Nutzern, nur die Teilmenge der Ereignisse zu abonnieren, die sie benötigen, und zwar in der ursprünglichen Reihenfolge.

Betrachten wir das Beispiel eines Einzelhändlers, der Microservices für das Streaming von auftragsbezogenen Ereignissen verwendet, aber verschiedene Funktionen an verschiedenen Orten verarbeitet. Benutzer der Anwendung, die nur neue Bestellungen bearbeiten wollen, benötigen keine Informationen über ausgelieferte Bestellungen oder Retouren, sondern nur Informationen über neue Bestellungen.

So arbeitet das fein abgestufte Filtern in der Praxis

Die Aufgabe eines Smart Brokers ist es auch, Informationen so zu veröffentlichen, dass ein fein abgestuftes Filtern von Ereignissen auf der Grundlage thematischer Taxonomien möglich ist. Nehmen wir zum Beispiel eine Luftfahrtbehörde, die die ankommenden und abgehenden Flüge eines bestimmten Flughafens verwaltet. Das klingt einfach, aber es gibt eine Vielzahl von Ereignissen für jeden einzelnen Flug.

Ein intelligenter Broker ist in der Lage, die Ereignissen für alle Flüge zu verwalten. Gleichzeitig ermöglicht er es aber den Abonnenten, die Ereignisse nach Fluggesellschaft, Ankunft/Abflug, pünktlich/verspätet, Ankunfts- und Abfluggate etc. aufzuschlüsseln. So können sie detaillierte Informationen auf der Grundlage der Faktoren erhalten, die für ihre Funktion oder ihren Verantwortungsbereich relevant sind.

2. Unterstützung von Event-Meshes

Unternehmen, die Event-Streaming in Echtzeit für betriebliche Anwendungen benötigen, müssen sich überlegen, wie ihr Broker ein Event-Mesh unterstützen kann. Ein Event-Mesh ist eine Architekturschicht, die aus einem Netzwerk von Event-Brokern besteht. Diese Broker sind so miteinander verbunden, dass Ereignisse von einer Anwendung dynamisch weitergeleitet und von jeder anderen Anwendung empfangen werden können – unabhängig davon, ob diese Anwendungen ohne Cloud oder in einer Private Cloud oder Public Cloud betrieben werden.

Ein Event-Mesh stellt alle Daten, die das Mesh berühren, bei Bedarf auf sichere und zuverlässige Weise genau dort zur Verfügung, wo und wann sie benötigt werden. Es bietet die Möglichkeit, Legacy-Anwendungen, Datenspeicher, moderne Microservices, SaaS, IoT und mobile Geräte dynamisch und in Echtzeit zu integrieren. Wenn IT und Analytik für die Integration von Legacy-Anwendungen und Betriebstechnologie für die Erfassung von Geräten eingesetzt werden, ist ein Event-Mesh der Klebstoff, der die alte Technologie mit der neuen verbindet.

Ein Beispiel hierfür wäre ein Fertigungsunternehmen, das IoT-Endgeräte für die Anlagenverfolgung, die Überwachung der Produktqualität und die vorausschauende Wartung einsetzt. Mit einem Event-Mesh können Sensorereignisse in Fertigungsprozessen für Echtzeit-Streaming-Analysen genutzt werden, um die Qualität zu verbessern und Probleme bei der Maschinenwartung frühzeitig zu erkennen. Unternehmen sind immer in Bewegung, und mit ihnen ändern sich auch die Erwartungen von Kunden und Mitarbeitern. Ein Event-Mesh, das die Bereitstellung von Daten in Echtzeit unterstützt, bedeutet: keine Wartezeiten. Nachfragespitzen werden geschickt abgefangen, damit die Systeme nicht zusammenbrechen.

3. Umfangreiche Anwendungsintegration

In komplexen Unternehmens-Ökosystemen verbinden intelligente Broker problemlos eine Vielzahl von Anwendungen und Geräten, ohne sich um die Übersetzung von verschiedenen Protokollen kümmern zu müssen. So verfügt beispielsweise ein verteiltes Unternehmen über viele kundenspezifische Anwendungen in vielen verschiedenen Sprachen, die Informationen austauschen müssen.

Operative Anwendungsfälle umfassen in der Regel diese komplexe Kombination aus Legacy-Systemen und modernen Anwendungen sowie weitere Datenströme von IoT-Geräten, die alle über unterschiedliche Sprachen und Protokolle kommunizieren. Auf diese Datenströme müssen möglicherweise auch Partner oder Drittanbieter über standardbasierte Protokolle wie AMQP, MQTT oder Webhooks zugreifen. Hier werden Smart Broker benötigt, um die Integration über die heterogene Anwendungslandschaft hinweg zu gewährleisten.

Auch SaaS-Anwendungen, Legacy-Systeme, Packaged Applications und Middleware müssen integriert werden. Dafür werden spezielle Event-Konnektoren benötigt, die diese Anwendungen „ereignisfähig“ machen. Der Event-Broker, auf den die Wahl fällt, sollte daher standardmäßig über eine Vielzahl solcher Konnektoren verfügen.

Geschäftsprozesse intelligenter gestalten – mit dem richtigen Broker

Wir leben in einer ereignisgesteuerten Welt. Geschäftsprozesse werden zunehmend datengesteuert, dynamisch und in Echtzeit ablaufen und erfordern ein Event-Streaming, das über die einfache analytische Übermittlung von Logdaten hinausgeht.

Hier muss der Smart Broker ansetzen und die Architektur bereitstellen, die es den Beteiligten ermöglicht, miteinander in Kontakt zu bleiben, immer auf dem gleichen Stand zu sein und aktuelle, datenbasierte Entscheidungen zu treffen. Dazu gehören Entwickler, Nutzer und Verbraucher, Mitarbeiter, Partner und Endkunden – eine Gemeinschaft von Stakeholdern, die immer größer wird.

(ID:49977645)