Die ereignisgesteuerte Architektur (EDA), setzt sich zunehmend in Unternehmen durch. Shawn McAllister, Chief Technology Officer und Chief Product Officer bei Solace, erklärt, dass Event-Broker sich unterscheiden und dass manche für bestimmte Aufgaben und Anwendungsfälle besser geeignet sind als andere. [...]
Die Implementierung von EDA-Plattformen (Event-Driven Architecture) ist in vollem Gange. 82 % 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 neuen IDC Infobrief hervor. Die Einführung von EDA geht Hand in Hand mit der digitalen Reife. 47 % 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.
Die Wahl des richtigen Brokers kann über den Erfolg Ihrer Strategie zur Integration von Echtzeitanwendungen entscheiden.
Ein Event-Broker ist eine nachrichtenorientierte Middleware. Sie 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 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.
So finden Sie den richtigen Smart Broker für Ihr Unternehmen
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.
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.
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, für den Sie sich entscheiden, sollte daher standardmäßig über eine Vielzahl solcher Konnektoren verfügen.
Heineken: ein Beispiel für umfassende Anwendungsintegration
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.
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.
*Der Autor Shawn McAllister ist Chief Technology Officer und Chief Product Officer bei Solace
Be the first to comment