Introduction to Event-Driven Architecture

Andrew Roberts
October 17, 2019
Introduction to
Event-Driven Architecture

Rapid Fire
EDA Use Cases
©Solace | Proprietary & Confidential
2

• Using EDA helps manufacturers blur
the lines between their IT and
operational technology (OT)
• In this industry, EDA helps move IoT
device data between buildings,
assembly lines, fleets, and containers
• Technical problems faced:
– large connection count, fan-in scenario
– processing data streams
– command & control
Digital Manufacturing
3

Financial Services
• Financial services companies use EDA to
power
– OMS and Trading Platforms
– FX Trading
– Payment Processing
– Market Data Distribution
– beating the latency of your competitors
– extreme messagevolumes
(10s of billions+ a day)
– need zero messageloss guarantees
– cutting network costs
4

• In the Gaming and Gambling industry, EDAs
are used to power
– Online Poker & Gaming
– Activity Tracking & Fraud Detection
– Race/Sports Betting
– extremely spikey message volumes, e.g. receiving a
wave of bets right before a horse race starts
– need zero messageloss guarantees for high value
messages
– need to be able to push out odds/rates in real-time
Gaming and Gambling
5

Retail
6
• EDAs help retailers handle:
– omnichannel inventory management
– customer support
– online stores
– personalized rewards programs
– need to guarantee that inventory
updates are processed in order, with zero
messageloss and no duplicates
– maintaining a globally accurate inventory
count across distributed applications

Government
• EDAs help governments:
–share information across agencies
–aggregate sensor and surveillance data
–large connection count, fan-in scenario
–processing data streams
–needing to provide Data-as-a-Service
across department silos
7

You’ve seen how EDAs are
used, so I get to quiz you:
What’s EDA?
8

What’s Event-Driven Architecture?
Event-Driven Architecture (EDA) is a design paradigm in which a
software component executes in response to receiving one or
more event notifications. EDA is more loosely coupled than the
client/server paradigm because the component that sends the
notification doesn’t know the identity of the receiving
components at the time of compiling.
Reference:
https://www.gartner.com/it-glossary/eda-event-driven-architecture
9

Unpacking Gartner’s definition of “Event-Driven Architecture” – 1/2
• “Event-driven architecture (EDA) is a design paradigm in which
a software component executes in response to receiving one or
more event notifications …
– event: “a significant change in state”
• (1) CAREFUL! State changes don’t have to be significant to be considered an event.
• (2) state != database
– event notification: a notification that there has been a change in state
10

Unpacking Gartner’s definition of “Event-Driven Architecture” – 2/2
• … EDA is more loosely coupled than the client/server paradigm
because the component that sends the notification doesn’t
know the identity of the receiving components at the time of
compiling."
– client/server paradigm: synchronous REST-driven request/reply
communication between a client, i.e. a web app, and a server
• (1) the very name tells you that this paradigm was made for the web
• (2) it seems like Gartner is telling us people are using this pattern outside the web
11

Let’s try to make this more relatable…
12

• Fundamentals
–Rapid Fire Use Cases ✅
–Intro to EDA ✅
–Intro to Messaging
• Demos + Hands On!
• Networking / Q&A
Tonight’s agenda
13

Intro to Messaging
14

How can my applicationsshare state changes with each other?
15
App A App B
?EVENT
EVENT
EVENT
Producer Consumer
? ? ?
How can App A tell App B that its
state has changed?

… Messaging!
16
App A App B
EVENT
EVENT
EVENT
Producer Consumer

Unless you’ve used messaging before, you probably associate inter
microservice communication with synchronous HTTP requests and replies
17
AppA
App B
Request Reply
Request/Reply Maybe you’ve worked with
Kubernetes before
Or even with a service mesh?

Did you know messages can be sent using communication patterns
other than request/reply?
18
AppA
App B
Request Reply
Request/Reply
Publish/SubscribeGuaranteed
Point-to-Point
Guaranteed
Request/Reply
Point-to-Point w/
Non-Exclusive
Consumption

Intro to Messaging
19
Jonathan Schabowsky - Senior Architect
REST vs Messaging for Microservices - Which One Is Best?
https://solace.com/blog/experience-awesomeness-event-driven-microservices/
A blog post written by my more senior colleague was very helpful to me
when I first joined Solace, so I want to walk through some sections from it.
Read the article in its entirety after tonight’s talk while everything’s still fresh
in your head, it’ll be worth it!

“Representational State Transfer (REST) was defined by Roy Fielding in his
2000 PhD dissertation entitled “Architectural Styles and the Design of
Network-based Software Architectures”.
20
Dr. Fielding was a part of the process of defining HTTP, and was called upon
time and again to defend the design choices of the web. Through his work
on HTTP, he distilled his model into a core set of principles, properties and
constraints, now called REST …”
Origin of REST

• “… Why is that important? It is my belief that we owe a great debt of
gratitude to Dr. Fielding. RESTful interactions have become vital to
enterprise computing as it enables many APIs on the web today.”
• With that said, lets define what problems REST solves best:
– Synchronous Request/Reply–HTTP (the network protocol on which REST is transported) itself is a
request/response protocol, so REST is a great fit for request/reply interactions.
– Publicly Facing APIs – Since HTTP is a de facto transport standard thanks to the work of the IETF,
the transport layer of the APIs created using REST are interoperable with every programming
language. Additionally, the messagepayload can be easily documented using tools such as Swagger
(OpenAPI Specification). And due to the wide range of security threats present on the internet, the
security ecosystem for REST is robust, from firewalls to OAUTH (Authentication/Authorization). ”
21

“Due to the popularity of RESTful services today, I see many companies
falling into the trap of using REST as an “all-in-one” tool...
22

“… Certainly, some of this popularity is due to the power REST provides
based on its own merits. Developers are also used to designing
applications with synchronous request/reply since APIs and Databases have
trained developers to invoke a method and expect an immediate
response.”
So when you design with REST, what happens if your service *does not*
produce an immediate response?
23

So when you design with REST, what happens if your
service *does not* produce an immediate response?
24
Orchestration w/ callbacks

25
Daisy chaining

26
Polling

“… REST and synchronous patterns have negative consequences that apply
primarily to the communication between microservice within the
enterprise and that in some cases are at odds with the principles of proper
microservice architecture:
(1)Tight Coupling
(2)Blocking
(3)Error Handling
27

Tight Coupling
29
• receivePayment()
• updateInventory()
• addToOrderHistory()
• runAnalyticsModel1()
• ..
• runAnalyticsModelN()
• ship()
Purchase Item Service
For every new service you add,
dev teams will have to update
the Purchase Item Service.
They’ll have to make sure all its
unit tests pass, coordinate a
production deployment, blah
blah blah blah blah

Blocking
31
your RESTful services
await deepThought()
When invoking a RESTful service, your service is blocked waiting for a response

Blocking
32
50 minutes laterA dabbing synchronous
microservice 
This is how synchronousmicroservices do laundry

Error Handling
34
Maybe you can pull this off on your own
using a finite-state machine
But that sounds hard.
• What if your application
reaches a state that is not
explicitly handled? BUG.
• Unit tests
• Bloated code
• Violates principal of single
purpose

“The solution to many of the shortcomings associated with
RESTful/synchronous interactions is to combine the principles of event-
driven architecture with microservices.
Event Driven Microservices (EDM) are inherently asynchronous and are
notified when it is time to perform work.”
35

“The benefits of messaging for event-driven microservices are many and
varied:
• Loose Coupling
• Non-Blocking
• Simple to Scale
• Greater Resiliency and Error Handling
36

Loose Coupling
37
According to Gartner, event brokers “are middleware
products that are used to facilitate, mediate and enrich the
interactionsof sources and handlersin event-driven
computing.”
“Event-driven architectures (EDA) is inherently
intermediated.Therefore, the intermediatingrole of event
brokering is a definitionalpart of EDA. All implementations
of event-driven applicationsmust use some technology in
the role of an event broker.”

Non-Blocking
38
*BEEP*
This is how asynchronousmicroservices do laundry

Simple to Scale
39
Non-Exclusive Consumption
…

Greater Resiliency and Error Handling
40
AppA App B
Guaranteed Delivery
EVENT

Intro to Messaging – Moral of the story
41
Embrace Eventual Consistency
“Eventual consistency is the idea that consistency will occur in the future, and it means accepting that
things may be out of sync for some time. It’s a pattern and concept that lets developers avoid using
nasty XA transactions. It’s the job of the eventing/messaging platform to ensure that these domain
change events are never lost before being appropriately handled by a service and acknowledged.
Some think the only benefit of eventual consistency is performance, but the real advantage is the
decoupling of the microservices since individual services are merely acting upon events that they
are interested in.”
Marc DiPasquale — Developer Advocate
Considerationsfor Developers BuildingEvent-Driven Microservices
https://solace.com/blog/considerations-developers-building-event-driven-microservices/

Let’s think how we can improve Amazon’s service
42
• receivePayment()
• updateInventory()
• addToOrderHistory()
• ..
• runAnalyticsModelN()
• ship()
Purchase Item Service

• Fundamentals
–Intro to EDA ✅
–Intro to Messaging ✅
• Demos + Hands On!
Tonight’s agenda
43

Demo + Hands On!
44

45

46

Check out the code here
• https://github.com/solacese/romo-robot
47

• Fundamentals
–Intro to EDA ✅
–Intro to Messaging ✅
• Demos + Hands On! ✅
Tonight’s agenda
48

Networking / Q&A
49

Please take our survey!
Scan the QR code or navigate to the link
50
http://bit.ly/Solaceworkshopnyc

References – Blog posts
51
• Event-Driven Architecture (EDA) - Gartner IT Glossary
https://www.gartner.com/it-glossary/eda-event-driven-architecture
• REST vs Messaging for Microservices - Which One Is Best?
https://solace.com/blog/experience-awesomeness-event-driven-microservices/
• Considerationsfor Developers BuildingEvent-Driven Microservices
https://solace.com/blog/considerations-developers-building-event-driven-microservices/

References – Messaging basics
52
• PubSub+ Concept Maps
https://docs.solace.com/PubSub-ConceptMaps.htm
• PubSub+ Event and Messaging Basics
https://docs.solace.com/PubSub-Basics/Basics.htm
• Messaging
https://docs.solace.com/PubSub-Basics/Core-Concepts-Messaging.htm
• Message Delivery Modes
https://docs.solace.com/PubSub-Basics/Core-Concepts-Message-Delivery-Modes.htm
• Message Models
https://docs.solace.com/PubSub-Basics/Core-Concepts-Message-Models.htm

Introduction to Event-Driven Architecture

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Introduction to Event-Driven Architecture

Semelhante a Introduction to Event-Driven Architecture (20)

Mais de Solace

Mais de Solace (20)

Último

Último (20)

Introduction to Event-Driven Architecture