Living without REST: Event-Driven Architecture

We got it: everybody knows how to create that pretty REST endpoint for your Microservices architecture. But even though REST over HTTP represents an important part of this whole new API world, most of the backend enterprise communications should be implemented using an Event-Driven Architecture on top of a Message-Driven Architecture.

Most developers got used to a request/reply mindset, and great technologies like traditional message brokers lost the spotlight. Basically because these developers believe that messaging is "hard". Join us on this session and we'll convince you that messaging is not hard: it's just not understood. And instead of adding a ton of code to control our fallbacks, tracing etc we can leverage tools like ActiveMQ, Kafka and Camel to create distributed, resilient, and performant Microservices architectures. Do you think that the code for doing this is clunky? Well, we'll prove otherwise.

Transcript

1. Living without REST: Event-Driven Architecture Edson Yanaga Director of Developer Experience @yanaga
2. Edson Yanaga @yanaga
3. Edson Yanaga @yanaga - Follow: - With a picture of the session - Mention @yanaga - With hashtag #fullstackporto Raffle Rules
4. https://bit.ly/mono2microdb
5. Code is easy, state is hard
6. Join developers.redhat.com 6 HTTP + REST
7. Latency Availability Performance
8. Cache and/or Polling
9. Eventual Consistency
10. Join developers.redhat.com 10 First, a look back at the past…
11. How was data managed 10 years ago?
12. Terrified about Entity Beans
13. Hibernate to the rescue!
14. Replacing XML with @Annotations
15. POJOs as an (Anemic) Domain Model
16. Event Sourcing
17. Join developers.redhat.com 17 ID CUSTOMER_ID BALANCE 1001 990 1000 1002 991 0 1003 991 -500 1004 992 300 Account
18. Join developers.redhat.com 18 ID ACCOUNT_ID TIMESTAMP OP AMOUNT 1 1001 1234567890 C 1000 2 1002 1234567891 C 200 3 1001 1234567900 D 300 4 1001 1234567995 D 150 Transactions
19. Enables you to think in the Events that happened in the system
20. CQS (Command-Query Separation) “Asking a question should not change the answer” (Bertrand Meyer)
21. CQRS (Command Query Responsibility Segregation)
22. Join developers.redhat.com 22 CQRS (Command Query Responsibility Segregation)
23. Join developers.redhat.com 23 ID NAME PHONE ADDRESS BIRTH 1 Burr 222-222-2323 901 South St 12/12/1968 2 Edson 222-333-3434 112 North Dr 03/03/1978 3 John 111-456-4545 666 Iron St 06/06/1966 4 Doe 333-789-7890 777 Boeing Dr 07/07/1977 INSERT INTO CUSTOMER(ID,NAME,PHONE,ADDRESS,BIRTH); SELECT * FROM CUSTOMER;
24. Join developers.redhat.com 24 SELECT ID, NAME, PHONE FROM CUSTOMER; SELECT ID, NAME, ADDRESS FROM CUSTOMER;
25. Join developers.redhat.com 25 CQRS with separate data stores
26. Join developers.redhat.com 26 SELECT ID, NAME, AGE, AVG_BILL FROM CUSTOMER_REPORT_VIEW; SELECT ID, PHONE, LAST_PAYMENT_AMOUNT FROM CUSTOMER_BILLING_VIEW;
27. CQRS & Event Sourcing
28. Join developers.redhat.com 28 ID CUSTOMER_ID BALANCE 1001 990 1000 1002 991 0 1003 991 -500 1004 992 300 Account ID ACCOUNT_ID TIMESTAMP OP AMOUNT 1 1001 1234567890 C 1000 2 1002 1234567891 C 200 3 1001 1234567900 D 300 4 1001 1234567995 D 150 Transactions
29. Join developers.redhat.com 29 ID CUSTOMER_ID BALANCE 1001 990 1000 1002 991 0 1003 991 -500 1004 992 300 Account ID ACCOUNT_ID TIMESTAMP OP AMOUNT 1 1001 1234567890 C 1000 2 1002 1234567891 C 200 3 1001 1234567900 D 300 4 1001 1234567995 D 150 Transactions READ MODEL WRITE MODEL
30. Why CQRS?
31. Performance
32. Distribution Availability Integration Analytics
33. Join developers.redhat.com 33 Canonical Source of Information (Write Data Store)
34. Join developers.redhat.com 34 Canonical Source of Information (Write Data Store) Read Data Store Read Data Store
35. Join developers.redhat.com 35 Canonical Source of Information (Write Data Store) Read Data Store Read Data Store Events Events
36. Join developers.redhat.com 36 Now, Back to the Future!
37. Event-Driven Architecture
38. Events are facts that happened in the system
39. Low-level Events vs Domain-level Events
40. Key Technologies
41. ActiveMQ Artemis Kafka Camel Debezium Quarkus Microprofile
42. Join developers.redhat.com 42 bit.ly/eda-tutorial
43. Join developers.redhat.com Feedback welcome! @yanaga
44. plus.google.com/+RedHat linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHatNews Thank you!