Event-Driven Architecture - 10 Jahre klüger

Von der https://www.software-architecture-alliance.de/2024

Vor zehn Jahren habe ich zum ersten Mal einen Vortrag über Event-driven Architecture gehalten. Kafka war gerade seit zwei Jahren Open Source und bei Version 0.8, und nur ein paar Wochen vorher war Java 8 erschienen, und die erste Version von Spring Boot. Damals war gerade das Label "reactive" populär, und so hieß er "From Enterprise To Reactive". Unter anderem habe ich das Saga-Pattern propagiert.

In den zehn Jahren habe ich einiges dazugelernt - musste aber vor allem auch vieles erst einmal verlernen. In diesem Vortrag ziehe ich eine kleine Bilanz: Welche Ansätze haben sich in den zehn Jahren bewährt, und welche waren für mich enttäuschend? (In welcher Kategorie wird wohl das Saga-Pattern wieder auftauchen?)

Nicht alles wird sich übertragen lassen, aber manche Einsicht kann vielleicht hilfreich sein.

Transcript

1. Event-Driven Architecture 10 Jahre klüger 1 Mastodon @lutzhuehnken@mastodon.social LinkedIn https://linkedin.com/in/lutzh Blog https://www.reactivesystems.eu/
2. @lutzhuehnken@mastodon.social EDA und ich.. - Mein erstes message-driven, asynchrones System: Bundesbank 2002 - An Event-Driven-Systemen gearbeitet z.B. für Zalando, ING, ista, Maersk - Zurzeit: Bank “green fieldˮ, mit Event-Driven Architecture, Microservices, DDD 2
3. @lutzhuehnken@mastodon.social • Kleiner Rückblick auf die letzten 10 Jahre • 3 Lehren aus 10 Jahren Event-Driven Architecture • 3 Lehren für die Arbeit als Architekt*in 3
4. @lutzhuehnken@mastodon.social 4 4 Wer gleich raten möchte, diese Begriffe merken 1. Actor System 2. Application Server 3. Cloud 4. DDD 5. Docker 6. Event Sourcing 7. Event-Driven Architecture 8. Kafka 9. Kubernetes 10. Message Queue 11. Microservices 12. Saga Pattern 13. Spring Boot
5. @lutzhuehnken@mastodon.social 5 5 Microservices
6. @lutzhuehnken@mastodon.social 6 6 Application Server
7. @lutzhuehnken@mastodon.social 7 7 Spring Boot
8. @lutzhuehnken@mastodon.social 8 8 Microservices - die letzten 10 Jahre Kaum zu glauben, dass das vor 10 Jahren Application Server noch Standard waren. In der Java-Welt hat Spring Boot einen riesigen Beitrag geleistet zur “Umkehrungˮ des Ansatzes. Wenn wir heute von Event-Driven Architecture reden, meinen wir in der Regel Event-Driven Microservices.
9. @lutzhuehnken@mastodon.social 9 9 Microservices - die letzten 10 Jahre Für das Problem, das sie lösen sollten - nämlich Teams, die gemeinsam an einem System arbeiten, zu erlauben, ihren Teil des Systems unabhängig von anderen zu deployen, zu skalieren, zu updaten, und möglicherweise mit einem anderen Tech Stack als die anderen - haben wir keine bessere Lösung.
10. @lutzhuehnken@mastodon.social 10 10 Apache Kafka
11. @lutzhuehnken@mastodon.social Kafka - a log based message broker 11 11
12. @lutzhuehnken@mastodon.social 12 12 Kafka - die letzten 10 Jahre Kafka ! Message Queue Kafka ist aus einer Nische zu dem Standard geworden. Das Architektur-Konzept “Log-based Message Brokerˮ hat sich als sehr geeignet für Event-Driven Architecture erwiesen. Manche kamen erst zu Kafka, und darüber (unfreiwillig?) zu EDA.
13. @lutzhuehnken@mastodon.social 13 13 Kubernetes
14. @lutzhuehnken@mastodon.social 14 14 Docker
15. @lutzhuehnken@mastodon.social 15 15 Cloud Native
16. @lutzhuehnken@mastodon.social 16 16 Domain-Driven Design
17. @lutzhuehnken@mastodon.social 17 17 Domain-Driven Design - 10 Jahre Vor 10 Jahren: Aggregates, Entities, Values, Repositories Schwerpunkt: Taktisches DDD. Heute: Bounded Contexts, Customer-Supplier, Conformist Schwerpunkt: Strategisches DDD. Das Thema war zwar durchgehend präsent, aber die Wahrnehmung hat sich geändert.
18. @lutzhuehnken@mastodon.social 18 18 Akka (stellvertretend für Actor Systems)
19. @lutzhuehnken@mastodon.social 19 19 Actor Systems Aktoren sind nebenläufige Einheiten, die ausschließlich über Nachrichten kommunizieren. Aktoren können drei verschiedene Reaktionen durchführen: • Nachrichten an sich selbst oder andere Aktoren verschicken. • Neue Aktoren erzeugen. • Das eigene Verhalten ändern. Der Nachrichtenaustausch erfolgt asynchron, d. h. der Sender einer Nachricht kann nach dem Abschicken sofort mit anderen Aktionen fortfahren und muss nicht warten, bis der Empfänger die Nachricht akzeptiert.
20. @lutzhuehnken@mastodon.social 20 20 Actor Systems - Let it Crash!
21. @lutzhuehnken@mastodon.social 21 21 Event Sourcing
22. @lutzhuehnken@mastodon.social 22 22 Event Sourcing
23. @lutzhuehnken@mastodon.social 23 23 Actor Systems, Event Sourcing - die letzen 10 Jahre Vor 10 Jahren hätte ich gedacht, dass die Themen heute relevanter wären. Missverhältnis von “zu lösendes Problemˮ und Ungewohntheit / Notwendigkeit des Umlernens? Würde ich unter “gute Ideen, die sich nicht durchgesetzt habenˮ einsortieren.
24. @lutzhuehnken@mastodon.social 24 24 Message Queue
25. @lutzhuehnken@mastodon.social 25 25 Saga Pattern
26. @lutzhuehnken@mastodon.social 26
27. @lutzhuehnken@mastodon.social 27 27 Event-Driven Architecture
28. @lutzhuehnken@mastodon.social 28 28 EDA  10 Jahre klüger..
29. @lutzhuehnken@mastodon.social 29 29 EDA  10 Jahre klüger.. 1. Makroarchitektur zuerst
30. @lutzhuehnken@mastodon.social 30 30 EDA vor 10 Jahren Innerhalb des Services: Event Sourcing, Event Driven (vert.x (à la node.js), Aktoren, etc.) Zwischen den Services: Irgendwas HTTP, Websockets, RMI, Message Queue, Workflow Engine, Framework)
31. @lutzhuehnken@mastodon.social 31 31 EDA heute Event Sourcing & lokales Eventing sind schwer vermittelbar. Die Leute lieben - anscheinend - CRUD 󰤇
32. @lutzhuehnken@mastodon.social 32 32 Transactional Outbox
33. @lutzhuehnken@mastodon.social 33 33 Wenn ich die Events in der Outbox einfach niemals lösche, könnte ich die Tabelle jederzeit wegwerfen und aus den Events wiederherstellen 🤔 Transactional Outbox vs. Event Sourcing
34. @lutzhuehnken@mastodon.social 34 34 Transactional Outbox vs. Event Sourcing
35. @lutzhuehnken@mastodon.social 35 35 Transactional Outbox vs. Event Sourcing
36. @lutzhuehnken@mastodon.social 36 36 EDA vor 10 Jahren Event Sourcing & lokales Eventing sind schwer vermittelbar. CRUD und Methodenaufrufe sind tief verankert. Aber ok: Für das, was wir heute erreichen wollen, ist die Kommunikation zwischen den Services ist das relevantere Problem.
37. @lutzhuehnken@mastodon.social Event-Driven Architecture = Event-Driven Microservices Ziele: • Laufzeit-Abhängigkeit zwischen Services beseitigen • Verhindern eines “Verteilten Monolithenˮ Die einzelnen Services können intern CRUD nutzen. Interessante Updates werden über Events publiziert. 37 37 EDA heute
38. @lutzhuehnken@mastodon.social 38 38 EDA  10 Jahre klüger.. 1. Makroarchitektur zuerst 2. Duale Natur von Events
39. @lutzhuehnken@mastodon.social 39 39 Events sind duale Wesen: Trigger und Daten
40. @lutzhuehnken@mastodon.social 40 40 🚫 “Primär DatenˮPerspektive Es geht um Service-Kollaboration, nicht um Datenreplikation. Anti-Pattern: Generische “Updatedˮ Events bei denen der Empfänger raten muss, was der Änderungsgrund ist. Event-Typen haben dann keine fachliche Bedeutung Ubiquitous Language!. Aber Ergebnis z.B. einer Event-Storming-Session sind Trigger, nicht Daten-Events. Events sind die kleinste Einheit einer Story.
41. @lutzhuehnken@mastodon.social 41 41 🚫 “Primär TriggerˮPerspektive Jeder Empfänger benötigt wahrscheinlich zumindest einige Attribute. Es gibt meistens mindestens einen Empfänger, der sich nicht für den Business-Prozess interessiert. Führt oft dazu, dass zusätzlich doch auch wide events generiert werden müssen (z.B. Bootstrapping, Analytics) (siehe auch Stream/Tabelle Dualität).
42. @lutzhuehnken@mastodon.social 42 42 Events sind duale Wesen: Trigger und Daten Im Zweifelsfall: Verwende Wide Events, die den Grund der Änderung als Attribut enthalten. Erlaubt ein Schema per Topic Dualität Schema/Tabelle), aber jeder Event hat auch eine klare Business-Bedeutung (im Event Storming-Fall: kann einem Post-It™ zugeordnet werden).
43. @lutzhuehnken@mastodon.social 43 43 EDA  10 Jahre klüger.. 1. Makroarchitektur zuerst 2. Duale Natur von Events 3. Finde den Flow
44. @lutzhuehnken@mastodon.social 44 44 Finde den Flow Event Command Query Beschreibt Etwas, was in der Vergangenheit geschehen ist. Eine Absicht, eine Operation auszuführen und/oder Daten zu ändern. Eine Anfrage nach Daten zu einem oder mehreren Objekten.
45. @lutzhuehnken@mastodon.social 45 45 🚫 Finde den Flow
46. @lutzhuehnken@mastodon.social 46 46 Finde den Flow Event Command Query Beschreibt Etwas, was in der Vergangenheit geschehen ist. Eine Absicht, eine Operation auszuführen und/oder Daten zu ändern. Eine Anfrage nach Daten zu einem oder mehreren Objekten. Antwort Keine Bestätigung (oder Fehler) Die angefragten Daten Kommunikation Fire-and-Forget Request-Response Request-Response
47. @lutzhuehnken@mastodon.social 47 47 Finde den Flow
48. @lutzhuehnken@mastodon.social 48 48 Kein Witz 󰣻
49. @lutzhuehnken@mastodon.social 49 49 Finde den Flow Events sind Fakten. Was die Abonnenten mit diesen Fakten machen, interessiert den Publizierer zur Laufzeit nicht. Events sind “Fire-and-Forgetˮ. Es gibt keinen Rückkanal. Nicht vergessen: Das Ziel ist, Laufzeitabhängigkeit zu beseitigen. Wenn ein Service zur Laufzeit auf die Antwort eines anderen warten muss, besteht eine Laufzeitabhängigkeit, egal, wie asynchron die Kommunikation ist.
50. @lutzhuehnken@mastodon.social 50 50 Finde den Flow Die Konsequenz: Einen Business-Prozess umzusetzen, ist keine Implementierungsaufgabe. Es ist eine Architekturaufgabe, einen Event Flow zu finden, der das Businessziel umsetzt. Z.B. mit Event Storming, geht aber auch anders.)
51. @lutzhuehnken@mastodon.social 51 51 EDA  10 Jahre klüger.. 1. Makroarchitektur zuerst 2. Duale Natur von Events 3. Finde den Flow
52. @lutzhuehnken@mastodon.social 52 52 Architekturarbeit - 10 Jahre klüger..
53. @lutzhuehnken@mastodon.social 53 53 Architekturarbeit - 10 Jahre klüger.. 1. Sei prinzipientreu (aber auch pragmatisch)
54. @lutzhuehnken@mastodon.social 54 54 Pragmatisch = gut, prinzipientreu = dogmatisch, realitätsfern, schlecht ? 🤔 Aber: • Wenn wir uns Prinzipien geben, müssen wir sie auch ernst nehmen. • Es gibt falsch verstandenen Pragmatismus. Pragmatismus vs. Prinzipientreue
55. @lutzhuehnken@mastodon.social 55 55 Falsch verstandener Pragmatismus 󰞹: Wir machen alles mit Events und Kafka. 󰠁: Aber hier benötige ich eine Response für meine Nachricht. 󰞹: Kein Problem. Dann legen wir einfach ein Response-Topic an, und dein Service abonniert das, und über die Correlation-ID findest du die Response zu deinem Event. Timeouts musst du irgendwie auch behandeln. Und das muss verteilt funktionieren und Crashes überstehen.
56. @lutzhuehnken@mastodon.social 56 56 Blog-Post von Confluent 2022 Und noch einmal: Kein Witz 󰣻
57. @lutzhuehnken@mastodon.social 57 57 Richtige Antwort 󰞹: Wir machen alles mit Events und Kafka. 󰠁: Aber hier benötige ich eine Response für meine Nachricht. 󰞹: Dann sind wir irgendwo falsch abgebogen. Finde den Flow! Wenn es wirklich nicht anders geht: Kafka ist nicht das richtige Tool. Mache einen HTTP/gRPC Call.)
58. @lutzhuehnken@mastodon.social 58 58 Tappe nicht in diese Falle. https://ronjeffries.com/xprog/articles/jatbaseball/ Pragmatismus vs. Prinzipientreue
59. @lutzhuehnken@mastodon.social 59 59 Kein Witz Teil 3 󰣻
60. @lutzhuehnken@mastodon.social 60 60 Pragmatismus vs. Prinzipientreue • Starte mit Prinzipien • Definiere Guidelines • Es ist nicht nur der Hammer in der Werkzeugkiste. Mache nicht die Lösung zum Ziel.
61. @lutzhuehnken@mastodon.social 61 61 Architekturarbeit - 10 Jahre klüger.. 1. Sei prinzipientreu (aber pragmatisch) 2. Reduziere Komplexität
62. @lutzhuehnken@mastodon.social 62 62 Komplexität https://x.com/bitfield/status/1411731604335214592
63. @lutzhuehnken@mastodon.social 63 63 Erinnert euch an “Finde den Flowˮ. Business-Prozesse bilden komplexe Abläufe ab. Nehmt sie nicht als in Stein gemeißelt und findet komplexe Lösungen dafür. Nehmt die Herausforderung an, die Komplexität zu reduzieren! Komplexität
64. @lutzhuehnken@mastodon.social 64 64 Architekturarbeit - 10 Jahre klüger.. 1. Sei prinzipientreu (aber pragmatisch) 2. Reduziere Komplexität 3. Investiere in Wirkung
65. @lutzhuehnken@mastodon.social Return on Investment 65 Sei nicht nur... .. sondern auch
66. @lutzhuehnken@mastodon.social Return on Investment 66 Sei nicht nur... .. sondern auch
67. @lutzhuehnken@mastodon.social 67 67 EDA  10 Jahre klüger.. 1. Makroarchitektur zuerst 2. Duale Natur von Events 3. Finde den Flow
68. @lutzhuehnken@mastodon.social 68 68 Architekturarbeit - 10 Jahre klüger.. 1. Sei prinzipientreu (aber pragmatisch) 2. Reduziere Komplexität 3. Investiere in Wirkung
69. Was denkt ihr? Lasst uns diskutieren! Und bitte gebt eine Bewertung ab ⭐⭐⭐⭐⭐ 69 Mastodon @lutzhuehnken@mastodon.social LinkedIn https://linkedin.com/in/lutzh Blog https://www.reactivesystems.eu/