Flexibel und Skalierbar
Der Event-driven-Ansatz
Software-Landschaften von Unternehmen sind kontinuierlichen Veränderungen ausgesetzt. Bei einer anstehenden Modernisierung geht es dabei meist um die Integration neuer Softwaresysteme mit geänderten Anforderungen. Weiterhin stehen technische Vorgaben wie Skalierbarkeit und Ausfallsicherheit im Fokus der beteiligten Projekte. Agile Entwicklungsteams gestalten in diesem Zuge oftmals die Schnittstellen der beteiligten Systeme komplett neu. Immer mehr bildet der Ereignis– bzw. Event-basierte Architekturansatz die Grundlage. Message Broker wie Apache Kafka setzen sich in den Technologie-Entscheidungen und Spezifikationen durch und ersetzen klassische synchrone Ansätze wie REST und SOAP. Was sind die Hintergründe hierfür und welche Vorteile bringt das mit sich? Welche Tools helfen bei der Entwicklung?
Was Event Driven ausmacht
Eine Event-getriebene Architektur (Event Driven Architecture, oder auch EDA) wird durch einen asynchronen Austausch von Nachrichten in einem strukturierten Format beschrieben. Ausgelöst werden diese durch fachliche Ereignisse, z.B. das Hinzufügen von Produkten zu einem Warenkorb. Die Komponenten einer EDA lassen sich in Produzenten oder Konsumenten der Ereignisse unterteilen. Die Rollen der Akteure können und sollen sich je nach Anwendungsfall natürlich auch ändern – je nach Richtung der Kommunikation zwischen den Services. Die Verteilung der Nachrichten geschieht über einen Message Broker, auch Mediator genannt. Dieser kennt die Topics der Austauschkanäle und steuert, welcher Akteur welches Ereignis erhält.
Die Produzenten wissen nicht genau, welche Konsumenten auf Events warten, und auch das Event kennt die Auswirkungen seines Auftretens nicht. Eine EDA unterscheidet sich von klassischen Client- und Server-Architekturen also dadurch, dass Services nicht direkt miteinander verbunden sind. Durch das fehlende Frage-Antwort-Muster entsteht lediglich eine lose Kopplung.
Die technische Umsetzung einer solchen Service-Choreografie variiert dann je nach eingesetzter Technologie. Bei der Wahl des geeigneten Werkzeugs spielen Kriterien wie Skalierbarkeit, Verfügbarkeit, aber auch die Anzahl bzw. der Durchsatz der Events eine große Rolle. Handelt es sich schon um Event Streaming oder hat der Austausch eher den Charakter einer Message Queue? Auch kann es von zentraler Bedeutung sein, ob die Nachrichten über einen längeren Zeitraum persistiert werden sollen, um Ereignisse – z.B. beim Ausfall eines beteiligten Systems – auch rückblickend betrachten zu können. Integrationen mit IoT oder Echtzeit-Datenanalysen können die Auswahl von in Frage kommenden Lösungen zusätzlich beeinflussen.
Die heutigen Cloud Angebote der Big Tech Unternehmen bieten bereits vorkonfigurierte Umgebungen für Message Broker-basierte Architekturen. Diese erleichtern den Einstieg in den Betrieb der hochverfügbaren und komplexen, verteilten Systeme. Als Beispiel sind hier Amazon Managed Streaming for Apache Kafka, das mit RabbitMQ kompatible Amazon MQ oder das sowohl mit Kafka als auch RabbitMQ kompatible Azure Event Hubs zu nennen. Die Cloud-Anbieter sorgen hier für die Bereitstellung eines vollständig verwalteten Event-Busses.
Event Driven Development
Bei BettercallPaul bildet die Betrachtung der fachlichen Domäne die Basis von Architektur-Entscheidungen in Softwareprojekten. Ein neuer Service wird in Workshops auf Basis der zugrundeliegenden Geschäftsprozesse und -ziele definiert. Wie in der realen Welt sind Events dabei ein sehr geeignetes Mittel, um Auslöser, Entscheidungspunkte und Ergebnisse der jeweiligen Aktivitäten zu beschreiben. Durch das Reagieren auf diese Ereignisse und die Weiterverarbeitung entstehen wiederrum neue Flows, welche ebenfalls Events produzieren. Dokumentationsmethoden wie UML und BPMN können dabei helfen, geeignete Spezifikationen für Event-getriebene Software zu erstellen.
Während der Softwareentwicklung gibt es eine ganze Reihe nützlicher Tools, die Entwickler:innen bei der Spezifikation und auch bei der Analyse von Events unterstützen:
- Die AsyncAPI Spezifikation erlaubt es, maschinen-lesbare Definition für asynchrone APIs zu erstellen und erleichtert damit die Dokumentation und Weiterentwicklung von eventbasierter Software
- Die CloudEvents Spezifikation liefert eine nützliche Anleitung, wie Events einheitlich und einem Standard entsprechend formatiert werden können, was die Kommunikation zwischen Teams vereinfacht und die Portabilität der Software erhöht
- Das Analyse-Dashboard Lenses erlaubt es, die Events in einem Apache Kafka Cluster in einfacher Weise auszuwerten, ähnlich einem Datenbank-Administrationstool
Für populäre Fullstack-Entwicklungsframeworks in der Java und .NET-Welt existieren einfache Integrationen mit Apache Kafka und natürlich auch dem weitaus länger am Markt etablierten Message Broker RabbitMQ. Beispiele hierfür sind Spring for Apache Kafka, die Quarkus Extension for Apache Kafka, Micronaut Kafka und die Kafka .NET Clients von Confluent und Oracle.
Wann sollte eine Architektur Event Driven sein?
Eine Event-getriebene Software bietet viele Vorteile, da sie dabei hilft, die durch Events ausgelösten Funktionen zeitlich begrenzt zu halten. Damit verbundene Transaktionen sind enger gefasst und auch ressourcenschonender. Insgesamt existieren in den beschriebenen Systemen typischerweise insgesamt weniger direkte Abhängigkeiten zwischen den Funktionen, was für eine bessere Wartbarkeit sorgt.
Eine Entscheidung zu einer EDA kann insbesondere dann in Erwägung gezogen werden, wenn bei einem bisher synchron verketteten Workflow mehrere Services beteiligt sind und man jedoch aufgrund des Anwendungsfalles nicht zwingend eine unmittelbare Antwort für die Aufgabe benötigt. Das Ablaufverhalten und die Ausfallsicherheit eines Systems lassen sich so erheblich verbessern. Im synchronen Szenario erwarten die aufrufenden Services stets eine Antwort innerhalb eines definierten Timeouts vom Server, um zum Ergebnis zu kommen. Zwar sorgen in REST-basierten Microservice-Architekturen sogenannte Circuit Breaker für zusätzliche Resilienz im Falle eines Ausfalls. Es ist jedoch nicht trivial, den Zustand des Systems und der übertragenen Daten aufrechtzuerhalten, der während der Anfragen bestand.
Die Alternative wäre hier, die Kommunikation konsequent asynchron zu gestalten und schon von vornherein Szenarien einzuplanen, in denen die Komponenten eines Systems nicht verfügbar sind. So wie es eben in Event-basierten Systemen der Fall ist. Denn hier ist es erlaubt, eine Historie von Events zu beliebigen Zeitpunkten einzuspielen und einen beliebigen Zustand der Applikation wiederherzustellen (Event Sourcing). Apache Kafka bringt mit seinem Event-Log eine eingebaute Persistenz-Lösung mit, mit der es möglich ist, Nachrichten direkt im Cluster zu speichern und diese sogar in Echtzeit zu analysieren.
Event-basierte Datenübertragung eignet sich also für alle Datenreplikationen oder auch als Alternative von klassischen Batches. Diese müssen nicht mehr als Ganzes in einer gegegeben Zeit übertragen werden, sondern können Nachricht für Nachricht über den Eventbus gesendet werden. Auch für neue Zuschnitte von monolithischer Software eignet sich Event Driven. In manchen Projekten beobachten wir, dass Event-getriebene Ansätze das zentrale Kommunikationssystem ganzer Enterprise Architekturen bilden, welche vor allem aus Microservices, aber auch SaaS-Produkten, ERP- und CRM-Systemen, Datensenken und IoT-Integrationen, bestehen können. Aufgrund ihrer Ähnlichkeit mit der realen Welt lassen sich Events intuitiv im Anforderungskatalog erfassen und in jeder Phase der Softwareentwicklung als Gestaltungselement einsetzen. Zu den Nachteilen einer EDA gehört ein komplexeres Monitoring des gesamten System-Zustandes, was jedoch durch Message Tracing oder die Event-Persistenz kompensiert werden kann. Einer allzu hohen Abhängigkeit von der Broker-Technologie kann man durch Facade-Implementierungen innerhalb der an der EDA beteiligten Services begegnen.
Über den Autor
Erik Panzer ist Software-Architekt bei BettercallPaul in Berlin.
Zurzeit beschäftigt er sich mit der Umsetzung von Cloud-Architekturen in der Automobilbranche und im öffentlichen Sektor. In der Vergangenheit hat er die Entwicklung skalierbarer und user-zentrierter Software für Startups und Enterprise-Kunden begleitet.
