This document summarizes an event on event-driven architecture held by Markus Eisele of Red Hat. The event covered lessons learned from transitions between middleware technologies like Java Message Service to event-driven architecture. It discussed realizations around the difficulties of scaling complex architectures and managing dependencies. Event-driven systems were presented as more distributed and requiring careful modeling of process flow. The talk suggested that distributed architecture, containers, APIs and DevOps are important success factors and that monitoring, testing and review are key parts of continuous integration and delivery.

1. Event-Driven Architecture:
A Thought Leadership Event
June 22, 2021
Going from Java
Message Service to
EDA
What middleware
adventures have taught us.

2. Markus Eisele
Developer Adoption Lead Red Hat EMEA
● 15 years developer and architect with Enterprise Java (Automotive, Finance,
Insurance)
● 6 years Developer Relations
● 150+ presentations, 200+ articles
twitter.com/myfear
https://www.linkedin.com/in/markuseisele/

3. Event-Driven
Architecture:
A
Thought
Leadership
Event

4. Innovation is the
source of IT evolution.
Event-Driven
Architecture:
A
Thought
Leadership
Event
Picture source: Apple.com

5. IT must evolve to support innovation
5

6. Monolith

7. Realizations
7
Gotta love Memory Management and Garbage
Collection!
JVM changed the way we build and run software. Less worry,
more magic. Better code quality, less errors and more value in
production.
Scaling Teams and Processes is possible.
Many ways to scale teams. Distributed version control helped
with large enterprise grade projects. Processes owned by
project teams.
Infrastructure and P2P are hard.
Hard to estimate and to order. Hard(er) to scale. Still
expensive. JMS doesn’t define message format just transport.
Point to point connections with a lot of processes and
paperwork.
Picture © https://twitter.com/nitdand/status/1399649347218776068

8. Enterprise Integration
Meta

9. Enterprise Integration
Meta
Meta

10. Realizations
10
Enterprise Integration is hard
Overcoming limitations of JMS with additional contracts and
standardized integration pattern and components. Integration
knowledge moves into CoCs.
Tools don’t solve your problems
EAI brings a lot of flexibility and complexity. Theoretically
easier to change in practice implemented once and never
changed. Meta data doesn’t stage easily from dev to prod.
Infrastructure is a pain.
There’s always more complexity to add. Scaling got a lot
harder. Again.

11. Service Oriented Architecture

12. Service Oriented Architecture

13. Realizations
13
Scaling Single Point of Failures is hard.
ESBs were great. Until they didn’t work or scale.
Staging Configuration and Meta Data is impossible.
We did not listen to the lessons learned from the EAI times. We
now have more meta data.
Responsibility Domains help managing complexity.
Organisational scaling became key to managing complexity.
We started to layer and cascade domains.
Picture © https://twitter.com/rotnroll666/status/1399651126828470272

14. Microservices Systems

15. Realizations
15
Managing Complexity is hard.
Technology choice exploded. Process knowledge is splattered
around teams. CNCF is a landscape not a product.
Application Server haven’t been that bad
Transaction, Security, Persistence, Scaling, Sessions,
component models. All the features moved into other places
and there’s more choice with less productivity.
Organizational capabilities have a lot of impact
Efficiency in development and production directly depends on
the organization and it’s capabilities.

16. Event Driven Architecture
Requ
Check
Check
Reg
All

17. Realizations
17
Kafka is … (not) a database.
There is no static state of your systems anymore. Your system
has the state. Not your database. Decide carefully what parts
of system state needs persistence and where.
Keeping track of your process is key.
Process flow moved into services, events and commands. It is
now as distributed as it has never been before. Monitor it.
Design it.
Missing encapsulation and wrong dependencies can
kill projects.
While you get away with microlyths and some design
weaknesses, you need to model even more carefully the more
distributed the process is.
Picture © https://twitter.com/hansolo_/status/1399646166480994312

18. What did we learn and
where are we going?
Event-Driven
Architecture:
A
Thought
Leadership
Event

19. Software Architecture Characteristics — Ref : Fundamentals of Software Architecture / Mark Richards and Neal Ford

20. Event-Driven
Architecture:
A
Thought
Leadership
Event

21. There’s so much more to success!
DISTRIBUTED
ARCHITECTURE
API CONTAINERS DEVOPS

22. There’s so much more to success!
CODE
BUILD TEST DEPLOY
MONITOR
REVIEW
Self-service
Automated
build & deploy
CI/CD
pipelines
Consistent
environments
Configuration
management
App logs &
metrics

23. Join Red Hat Developer.
Build here. Go anywhere.
facebook.com/RedHatDeveloperProgram
youtube.com/RedHatDevelopers
twitter.com/rhdevelopers
linkedin.com/showcase/red-hat-developer

24. A monthly webinar series for developers.
#OpenShift #Microservices #Knative #Quarkus #Kafka #Cloudnative
#Container
https://red.ht/OpenDevHour

25. linkedin.com/company/red-hat
youtube.com/user/RedHatVideos
facebook.com/redhatinc
twitter.com/RedHat
Red Hat is the world’s leading provider of
enterprise open source software solutions.
Award-winning support, training, and consulting
services make
Red Hat a trusted adviser to the Fortune 500.
Q&A
25

26. Event-Driven
Architecture:
A
Thought
Leadership
Event

28. Event-Driven
Architecture:
A
Thought
Leadership
Event