Events in großem Maßstab

Event-Driven Architecture liegt voll im Trend. Das ist auch verständlich, ermöglicht diese Architektur doch eine lose Kopplung zwischen den Komponenten eines Systems, erhöht die Flexibilität und Skalierbarkeit und verbessert die Reaktionsfähigkeit auf Änderungen oder Ereignisse in Echtzeit.

82 Prozent der IT-Führungskräfte geben an, dass ihre Unternehmen EDA in den nächsten 24 Monaten für 2-3 neue Anwendungsfälle einsetzen wollen. Das geht aus einem IDC Infobrief hervor. 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 & Collect, vorbeugende Wartung von Maschinen, digitales Twinning 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.

Der Event-Broker sorgt für die zuverlässige Übertragung von Ereignissen zwischen den verschiedenen Komponenten eines Systems und fungiert als Vermittler zwischen Publishern und Subscribern. Somit ist der Broker 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.

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.

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.

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 Sie sich 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.

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:

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.

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.

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.

Stellen Sie sich ein Fertigungsunternehmen vor, 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, dass Sie nicht warten müssen. Nachfragespitzen werden geschickt abgefangen, damit die Systeme nicht zusammenbrechen.

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, für den Sie sich entscheiden, sollte daher standardmäßig über eine Vielzahl solcher Konnektoren verfügen.

Heineken, ein multinationales Brauereiunternehmen mit Geschäftseinheiten in mehr als 190 Ländern, ist ein perfektes Beispiel dafür, dass EDA-Implementierungen immer ausgefeilter werden. Heineken verwendet einen ereignisgesteuerten Integrationsansatz, um das Streaming von Ereignissen in Tausenden von geschäftskritischen Anwendungen zu unterstützen, die Zahlungen, Logistik, Bestandsmanagement und vieles mehr betreffen. Nur ein Smart Broker kann diesen durchgängigen, schnellen, zuverlässigen und robusten Integrationsprozess über alle wichtigen Geschäftsfunktionen hinweg gewährleisten.

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.

Shawn McAllister, Chief Technology Officer & Chief Product Officer, ist verantwortlich für die Strategie und Bereitstellung der Solace PubSub+ Event-Streaming- und Event-Management-Plattform. Er leitet ein Team von hochqualifizierten Entwicklern und Software-Architekten. Bevor er zu Solace kam, leitete Shawn McAllister Software-, Hardware- und Testentwicklungsteams bei Newbridge Networks (später Alcatel Canada), wo er für die Entwicklung von Funktionen für ATM- und Ethernet-Switches und den 7750 Multiservice-IP-Router verantwortlich war. Shawn McAllister hat einen Bachelor-Abschluss in Mathematik mit den Schwerpunkten Informatik und Kombinatorik/Optimierung von der University of Waterloo.