Tweet
Tweet

Slide 1

Slide 1 text

Event-Driven Architecture 10 Jahre klüger 1 Mastodon @[email protected] LinkedIn https://linkedin.com/in/lutzh Blog https://www.reactivesystems.eu/

Slide 2

Slide 2 text

@[email protected] 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

Slide 3

Slide 3 text

@[email protected] ● 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

Slide 4

Slide 4 text

@[email protected] 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

Slide 5

Slide 5 text

@[email protected] 5 5 Microservices

Slide 6

Slide 6 text

@[email protected] 6 6 Application Server

Slide 7

Slide 7 text

@[email protected] 7 7 Spring Boot

Slide 8

Slide 8 text

@[email protected] 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.

Slide 9

Slide 9 text

@[email protected] 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.

Slide 10

Slide 10 text

@[email protected] 10 10 Apache Kafka

Slide 11

Slide 11 text

@[email protected] Kafka - a log based message broker 11 11

Slide 12

Slide 12 text

@[email protected] 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.

Slide 13

Slide 13 text

@[email protected] 13 13 Kubernetes

Slide 14

Slide 14 text

@[email protected] 14 14 Docker

Slide 15

Slide 15 text

@[email protected] 15 15 Cloud Native

Slide 16

Slide 16 text

@[email protected] 16 16 Domain-Driven Design

Slide 17

Slide 17 text

@[email protected] 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.

Slide 18

Slide 18 text

@[email protected] 18 18 Akka (stellvertretend für Actor Systems)

Slide 19

Slide 19 text

@[email protected] 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.

Slide 20

Slide 20 text

@[email protected] 20 20 Actor Systems - Let it Crash!

Slide 21

Slide 21 text

@[email protected] 21 21 Event Sourcing

Slide 22

Slide 22 text

@[email protected] 22 22 Event Sourcing

Slide 23

Slide 23 text

@[email protected] 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.

Slide 24

Slide 24 text

@[email protected] 24 24 Message Queue

Slide 25

Slide 25 text

@[email protected] 25 25 Saga Pattern

Slide 26

Slide 26 text

@[email protected] 26

Slide 27

Slide 27 text

@[email protected] 27 27 Event-Driven Architecture

Slide 28

Slide 28 text

@[email protected] 28 28 EDA  10 Jahre klüger..

Slide 29

Slide 29 text

@[email protected] 29 29 EDA  10 Jahre klüger.. 1. Makroarchitektur zuerst

Slide 30

Slide 30 text

@[email protected] 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)

Slide 31

Slide 31 text

@[email protected] 31 31 EDA heute Event Sourcing & lokales Eventing sind schwer vermittelbar. Die Leute lieben - anscheinend - CRUD 󰤇

Slide 32

Slide 32 text

@[email protected] 32 32 Transactional Outbox

Slide 33

Slide 33 text

@[email protected] 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

Slide 34

Slide 34 text

@[email protected] 34 34 Transactional Outbox vs. Event Sourcing

Slide 35

Slide 35 text

@[email protected] 35 35 Transactional Outbox vs. Event Sourcing

Slide 36

Slide 36 text

@[email protected] 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.

Slide 37

Slide 37 text

@[email protected] 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

Slide 38

Slide 38 text

@[email protected] 38 38 EDA  10 Jahre klüger.. 1. Makroarchitektur zuerst 2. Duale Natur von Events

Slide 39

Slide 39 text

@[email protected] 39 39 Events sind duale Wesen: Trigger und Daten

Slide 40

Slide 40 text

@[email protected] 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.

Slide 41

Slide 41 text

@[email protected] 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).

Slide 42

Slide 42 text

@[email protected] 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).

Slide 43

Slide 43 text

@[email protected] 43 43 EDA  10 Jahre klüger.. 1. Makroarchitektur zuerst 2. Duale Natur von Events 3. Finde den Flow

Slide 44

Slide 44 text

@[email protected] 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.

Slide 45

Slide 45 text

@[email protected] 45 45 🚫 Finde den Flow

Slide 46

Slide 46 text

@[email protected] 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

Slide 47

Slide 47 text

@[email protected] 47 47 Finde den Flow

Slide 48

Slide 48 text

@[email protected] 48 48 Kein Witz 󰣻

Slide 49

Slide 49 text

@[email protected] 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.

Slide 50

Slide 50 text

@[email protected] 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.)

Slide 51

Slide 51 text

@[email protected] 51 51 EDA  10 Jahre klüger.. 1. Makroarchitektur zuerst 2. Duale Natur von Events 3. Finde den Flow

Slide 52

Slide 52 text

@[email protected] 52 52 Architekturarbeit - 10 Jahre klüger..

Slide 53

Slide 53 text

@[email protected] 53 53 Architekturarbeit - 10 Jahre klüger.. 1. Sei prinzipientreu (aber auch pragmatisch)

Slide 54

Slide 54 text

@[email protected] 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

Slide 55

Slide 55 text

@[email protected] 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.

Slide 56

Slide 56 text

@[email protected] 56 56 Blog-Post von Confluent 2022 Und noch einmal: Kein Witz 󰣻

Slide 57

Slide 57 text

@[email protected] 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.)

Slide 58

Slide 58 text

@[email protected] 58 58 Tappe nicht in diese Falle. https://ronjeffries.com/xprog/articles/jatbaseball/ Pragmatismus vs. Prinzipientreue

Slide 59

Slide 59 text

@[email protected] 59 59 Kein Witz Teil 3 󰣻

Slide 60

Slide 60 text

@[email protected] 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.

Slide 61

Slide 61 text

@[email protected] 61 61 Architekturarbeit - 10 Jahre klüger.. 1. Sei prinzipientreu (aber pragmatisch) 2. Reduziere Komplexität

Slide 62

Slide 62 text

@[email protected] 62 62 Komplexität https://x.com/bitfield/status/1411731604335214592

Slide 63

Slide 63 text

@[email protected] 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

Slide 64

Slide 64 text

@[email protected] 64 64 Architekturarbeit - 10 Jahre klüger.. 1. Sei prinzipientreu (aber pragmatisch) 2. Reduziere Komplexität 3. Investiere in Wirkung

Slide 65

Slide 65 text

@[email protected] Return on Investment 65 Sei nicht nur... .. sondern auch

Slide 66

Slide 66 text

@[email protected] Return on Investment 66 Sei nicht nur... .. sondern auch

Slide 67

Slide 67 text

@[email protected] 67 67 EDA  10 Jahre klüger.. 1. Makroarchitektur zuerst 2. Duale Natur von Events 3. Finde den Flow

Slide 68

Slide 68 text

@[email protected] 68 68 Architekturarbeit - 10 Jahre klüger.. 1. Sei prinzipientreu (aber pragmatisch) 2. Reduziere Komplexität 3. Investiere in Wirkung

Slide 69

Slide 69 text

Was denkt ihr? Lasst uns diskutieren! Und bitte gebt eine Bewertung ab ⭐⭐⭐⭐⭐ 69 Mastodon @[email protected] LinkedIn https://linkedin.com/in/lutzh Blog https://www.reactivesystems.eu/