Event-Driven Architecture - 10 Jahre klüger

Slide 1

Slide 1 text

Event-Driven Architecture 10 Jahre klüger 1 Mastodon @lutzhuehnken@mastodon.social LinkedIn https://linkedin.com/in/lutzh Blog https://www.reactivesystems.eu/

Slide 2

Slide 2 text

@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

Slide 3

Slide 3 text

@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

Slide 4

Slide 4 text

@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

Slide 5

Slide 5 text

@lutzhuehnken@mastodon.social 5 5 Microservices

Slide 6

Slide 6 text

@lutzhuehnken@mastodon.social 6 6 Application Server

Slide 7

Slide 7 text

@lutzhuehnken@mastodon.social 7 7 Spring Boot

Slide 8

Slide 8 text

@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.

Slide 9

Slide 9 text

@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.

Slide 10

Slide 10 text

@lutzhuehnken@mastodon.social 10 10 Apache Kafka

Slide 11

Slide 11 text

@lutzhuehnken@mastodon.social Kafka - a log based message broker 11 11

Slide 12

Slide 12 text

@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.

Slide 13

Slide 13 text

@lutzhuehnken@mastodon.social 13 13 Kubernetes

Slide 14

Slide 14 text

@lutzhuehnken@mastodon.social 14 14 Docker

Slide 15

Slide 15 text

@lutzhuehnken@mastodon.social 15 15 Cloud Native

Slide 16

Slide 16 text

@lutzhuehnken@mastodon.social 16 16 Domain-Driven Design

Slide 17

Slide 17 text

@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.

Slide 18

Slide 18 text

@lutzhuehnken@mastodon.social 18 18 Akka (stellvertretend für Actor Systems)

Slide 19

Slide 19 text

@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.

Slide 20

Slide 20 text

@lutzhuehnken@mastodon.social 20 20 Actor Systems - Let it Crash!

Slide 21

Slide 21 text

@lutzhuehnken@mastodon.social 21 21 Event Sourcing

Slide 22

Slide 22 text

@lutzhuehnken@mastodon.social 22 22 Event Sourcing

Slide 23

Slide 23 text

@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.

Slide 24

Slide 24 text

@lutzhuehnken@mastodon.social 24 24 Message Queue

Slide 25

Slide 25 text

@lutzhuehnken@mastodon.social 25 25 Saga Pattern

Slide 26

Slide 26 text

@lutzhuehnken@mastodon.social 26

Slide 27

Slide 27 text

@lutzhuehnken@mastodon.social 27 27 Event-Driven Architecture

Slide 28

Slide 28 text

@lutzhuehnken@mastodon.social 28 28 EDA  10 Jahre klüger..

Slide 29

Slide 29 text

@lutzhuehnken@mastodon.social 29 29 EDA  10 Jahre klüger.. 1. Makroarchitektur zuerst

Slide 30

Slide 30 text

@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)

Slide 31

Slide 31 text

@lutzhuehnken@mastodon.social 31 31 EDA heute Event Sourcing & lokales Eventing sind schwer vermittelbar. Die Leute lieben - anscheinend - CRUD 󰤇

Slide 32

Slide 32 text

@lutzhuehnken@mastodon.social 32 32 Transactional Outbox

Slide 33

Slide 33 text

@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

Slide 34

Slide 34 text

@lutzhuehnken@mastodon.social 34 34 Transactional Outbox vs. Event Sourcing

Slide 35

Slide 35 text

@lutzhuehnken@mastodon.social 35 35 Transactional Outbox vs. Event Sourcing

Slide 36

Slide 36 text

@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.

Slide 37

Slide 37 text

@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

Slide 38

Slide 38 text

@lutzhuehnken@mastodon.social 38 38 EDA  10 Jahre klüger.. 1. Makroarchitektur zuerst 2. Duale Natur von Events

Slide 39

Slide 39 text

@lutzhuehnken@mastodon.social 39 39 Events sind duale Wesen: Trigger und Daten

Slide 40

Slide 40 text

@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.

Slide 41

Slide 41 text

@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).

Slide 42

Slide 42 text

@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).

Slide 43

Slide 43 text

@lutzhuehnken@mastodon.social 43 43 EDA  10 Jahre klüger.. 1. Makroarchitektur zuerst 2. Duale Natur von Events 3. Finde den Flow

Slide 44

Slide 44 text

@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.

Slide 45

Slide 45 text

@lutzhuehnken@mastodon.social 45 45 🚫 Finde den Flow

Slide 46

Slide 46 text

@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

Slide 47

Slide 47 text

@lutzhuehnken@mastodon.social 47 47 Finde den Flow

Slide 48

Slide 48 text

@lutzhuehnken@mastodon.social 48 48 Kein Witz 󰣻

Slide 49

Slide 49 text

@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.

Slide 50

Slide 50 text

@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.)

Slide 51

Slide 51 text

@lutzhuehnken@mastodon.social 51 51 EDA  10 Jahre klüger.. 1. Makroarchitektur zuerst 2. Duale Natur von Events 3. Finde den Flow

Slide 52

Slide 52 text

@lutzhuehnken@mastodon.social 52 52 Architekturarbeit - 10 Jahre klüger..

Slide 53

Slide 53 text

@lutzhuehnken@mastodon.social 53 53 Architekturarbeit - 10 Jahre klüger.. 1. Sei prinzipientreu (aber auch pragmatisch)

Slide 54

Slide 54 text

@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

Slide 55

Slide 55 text

@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.

Slide 56

Slide 56 text

@lutzhuehnken@mastodon.social 56 56 Blog-Post von Confluent 2022 Und noch einmal: Kein Witz 󰣻

Slide 57

Slide 57 text

@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.)

Slide 58

Slide 58 text

@lutzhuehnken@mastodon.social 58 58 Tappe nicht in diese Falle. https://ronjeffries.com/xprog/articles/jatbaseball/ Pragmatismus vs. Prinzipientreue

Slide 59

Slide 59 text

@lutzhuehnken@mastodon.social 59 59 Kein Witz Teil 3 󰣻

Slide 60

Slide 60 text

@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.

Slide 61

Slide 61 text

@lutzhuehnken@mastodon.social 61 61 Architekturarbeit - 10 Jahre klüger.. 1. Sei prinzipientreu (aber pragmatisch) 2. Reduziere Komplexität

Slide 62

Slide 62 text

@lutzhuehnken@mastodon.social 62 62 Komplexität https://x.com/bitfield/status/1411731604335214592

Slide 63

Slide 63 text

@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

Slide 64

Slide 64 text

@lutzhuehnken@mastodon.social 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

@lutzhuehnken@mastodon.social Return on Investment 65 Sei nicht nur... .. sondern auch

Slide 66

Slide 66 text

@lutzhuehnken@mastodon.social Return on Investment 66 Sei nicht nur... .. sondern auch

Slide 67

Slide 67 text

@lutzhuehnken@mastodon.social 67 67 EDA  10 Jahre klüger.. 1. Makroarchitektur zuerst 2. Duale Natur von Events 3. Finde den Flow

Slide 68

Slide 68 text

@lutzhuehnken@mastodon.social 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 @lutzhuehnken@mastodon.social LinkedIn https://linkedin.com/in/lutzh Blog https://www.reactivesystems.eu/