Living without REST: Event-Driven Architecture

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.

14493d3489b1441918bfddfe298415d9?s=128

Edson Yanaga

April 25, 2019
Tweet

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!