Events First: Resiliente und skalierbare Microservices

Die Erwartungen an Microservices sind groß: Sie sollen nicht nur die Entwicklung beschleunigen, sondern auch höchste Qualitätsanforderungen erfüllen. Wo monolithische Enterprise-Systeme unter Last ächzen, versprechen sie Stabilität und Skalierbarkeit. In der Umsetzung bleibt dies mitunter auf der Strecke. Es werden Systeme gebaut, in denen jeder Service auf alle anderen Services angewiesen ist, oder deren Durchsatz durch ineffiziente Kommunikation begrenzt wird. Event-basierte Architekturmuster können das Versprechen der resilienten, skalierbaren Systeme einlösen.
Der Events-First-Ansatz betrifft nicht nur die Kommunikation zwischen Services, sondern auch, wie wir mit (globalem) Zustand umgehen. Ein solches System zu entwerfen ist eine Herausforderung für Softwarearchitektinnen und -architekten. Aus der Domain-driven-Design-Community kommt die Technik des Event Stormings. Sie hilft uns, den Fokus zunächst weniger auf die statischen Eigenschaften der Domäne wie dem Datenmodell zu legen.
Der Vortrag zeigt, wie eine eventbasierte Architektur zu besseren Microservices führt, und wo wir dafür in der Architektur umdenken müssen.

Vortrag von der W-JAX 2018, München, am 7.11.2018

Transcript

1. Events First: Resiliente & Skalierbare Microservices 7.11.2018
 W-JAX @lutzhuehnken
2. „CRUD“ Service Service RDMBS Außen welt
3. Außen welt Service A Service B Service C RDBMS RDBMS RDMBS „Synchrone“ µServices
4. Wie skalieren wir? Service RDMBS Außen welt
5. Service B RDBMS „Stateless“ Services Service B Service B
6. Service B Master Master / Replica Service B Service B Replica Replica
7. Außen welt Service A Service B Service C RDBMS RDBMS RDMBS Wie resilient sind wir?
8. Außen welt Service A Service B Failure RDBMS RDBMS RDMBS Fehler kaskadieren
9. 9 „A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable.“ Leslie Lamport
10. Was könnte nur die Lösung sein?
11. Event • Events sind Fakten • immer in Vergangenheitsform, etwas, was passiert ist • Events können nicht zurückgenommen werden • sie können höchstens ignoriert werden • Events sind unveränderlich
12. Arten von Events (nach Martin Fowler: What do you mean by “Event-Driven”?) • Event Notification • es ist etwas passiert • Event-Carried State Transfer • das hier sind die Änderungen • Event-Sourcing • speichere Events statt Zustand
13. 1. Skalierbarkeit: Event Sourcing 2. Resilienz: Event Streaming 3. Design: Event Storming Was uns interessiert
14. EVENTSOURCING
15. Ziel: Scale Out
16. Event Sourcing - Prinzip Event Event Event Command A A' • Wir senden ein Kommando an unser „Aggregat“ A. • A validiert Kommando, es resultiert in Fehler oder Event(s). • Die Events werden persistiert. • Als Reaktion auf einen Event ändert A seinen Zustand zu A’
17. Event Sourcing - Philosophie
18. Wie skalieren wir? Node A Node B Node C X B A Z X Y N M „Cluster Sharding“
19. Service B Event Journal Wie skalieren wir? Service B Service B Event Journal Event Journal
20. State, Locks, Contention.. Shared Mutable Share Nothing Immutable
21. „All computers wait at the same speed.“ 21
22. S S Service B RDBMS Die „Stateless“ Illusion Service B Service B Stateless Shared Mutable State
23. S Service B Event Journal „Embrace the state“ Service B Service B Event Journal Event Journal Share-nothing Mutable State
24. Projection Read Side Wie lesen wir? CQRS Event Journal Read Side Projection
25. ES / CRQS- Technologie Event Sourcing / Command Query Responsibility Segregation • Write Side (Event Journal) • z.B. Cassandra - skaliert, schnelle Schreibzugriffe • Read Side • z.B. RDMBS - erlaubt SQL Tooling zu nutzen • oder.. Elastic Search, Hadoop/Spark, .. • „Polyglot Persistence“ (CQRS Read Side heißt immer: Eventual Consistency)
26. EVENTSTREAMING
27. Ziel: Bulkheads
28. Außen welt Service A Service B Service C Event Journal Event Journal Event Journal Ohne Event Streaming
29. Außen welt Service A Service B Service C Event Journal Event Journal Event Journal Mit Event Streaming Event Stream
30. Event Streaming • Services sprechen nicht mehr synchron miteinander, sondern publizieren und abonnieren Events • Tell, don’t ask! • Availability vs. Authority • Wieder: Eventual Consistency
31. Außen welt Service A Service B Failure Event Journal Event Journal Event Journal Resilienz Event Stream
32. Event Streaming - Technologie • Platzhirsch: Apache Kafka • Bewährt, aber Vorsicht vor Marketing-Versprechen • Auf AWS: Kinesis • Möglicherweise Alternativen (nicht getestet) • Chronicle Queue • NATS • Pulsar
33. EVENTSTORMING
34. PPT Master 16:9 / Edition 2018 „Going to microservices is like going from Newton’s physics to Einstein’s physics. Newton’s time marched forward uniformly with instant knowledge at a distance. Before microservices, distributed computing strove to make many systems look like one with RPC, 2PC etc.. In Einstein’s universe, everything is relative to one’s perspective.“ Pat Helland
35. Die Rettung: Event Storming!
36. EventStorming Starte mit Events. Erzähle eine Geschichte. Seat selected
37. EventStorming Wenn die Geschichte erzählt ist, überlege, was / wer die Events auslöst. Seat selected Choose seat
38. EventStorming Wer muss was wissen, um das Kommando zu verarbeiten? So finden wir unsere Aggregate. Seat selected Choose seat Seat map
40. „It is not the things that matter in early stages of design… …it is the things that happen.“ Russ Miles http:/ /www.russmiles.com/essais/going-events-first-for-microservices-with-event-storming-and-ddd 40
41. Wenn ihr nur eine Sache mitnehmt aus diesem Vortrag…
42. Fazit • Ihr könnt wirklich skalierbare und resiliente Microservices bauen, die Technologie ist da.* • Die wahre Hürde ist das Design: Die asynchrone, verteilte Natur, und die damit verbundene Unsicherheit (eventual consistency), akzeptieren und damit arbeiten. • Event Storming kann dabei eine sehr große Hilfe sein. (Ich hab’s ausprobiert, funktioniert ;)
43. Außen welt Service A Service B Service C Event Journal Event Journal Event Journal Bedenkenträger: Event Stream ist SPOF Failure
44. Bedenkenträger: Zu komplex • CQRS heißt ja schonmal mindestens zwei Datenbanken • Cassandra heißt mind. 3 Knoten • Kafka heißt mindestens 3 Knoten für Kafka plus mindestens 3 Knoten für Zookeeper
45. 45 Scalability cannot be an after-thought. It requires applications and platforms to be designed with scaling in mind, … Werner Vogels
46. Projection Read Side Bedenkenträger: Änderungen sofort sehen Event Journal Read Side Projection Aggregate (can be read)
47. Bedenkenträger: Out-of-Order Events, Duplicates… Außen welt Service A Service B Service C Event Event Event Event Stream Deal with Uncertainty!
48. 1. Skalierbar mit Event Sourcing ✔ 2. Resilient mit Event Streaming ✔ 3. Events First mit Event Storming ✔ Yeah, Events!
49. Bitte lesen / anschauen • Pat Helland • „Beyond Distributed Transactions“ • „Data on the Outside versus Data on the Inside“ • Jonas Boner • „Designing Events First Microservices“ • alles andere auch • Vaughn Vernon • „Dealing with Uncertainty“
50. Fragen, bitte! www.innoq.com Kontakt: Lutz Hühnken lutz.huehnken@innoq.com @lutzhuehnken INNOQ seit 1.11. auch in Hamburg. Wir suchen Verstärkung für unser Hamburger Team! INNOQ auf der W-JAX: Auf diesem Stockwerk (Obergeschoss), gegenüber von Audi.
51. Noch ein paar Links • http://www.russmiles.com/essais/going-events-first-for- microservices-with-event-storming-and-ddd • http://ziobrando.blogspot.de/2013/11/introducing-event- storming.html • https://leanpub.com/introducing_eventstorming • https://www.lagomframework.com • https://blog.redelastic.com/corporate-arts-crafts-modelling- reactive-systems-with-event-storming-73c6236f5dd7