You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"Events" have recently been given a lot of attention as a very powerful means of communication between components. They pop up almost everywhere in different shapes and forms, and for different reasons. Unfortunately, they often completely miss their purpose, and instead of decoupling components, they subtly introduce an implicit coupling in logic.
The distributed big ball of mud is born.
Throwing more technologies at it won't solve the problem, all it will do is simply introduce a new layer of mud on top of the old.
In this session, I will take a few steps back and look at three reasons why components need to communicate. I will demonstrate that by considering the reason of the communication, you can select suitable routing patterns, choose an appropriate protocol and technology to transport each type, and end up with proper decoupling of components. This decoupling means that it doesn't matter anymore whether the messages are handled in the same process as the sender, on different hosts or even in different data centers altogether. This so-called location transparency then becomes a big enabler for building evolutionary "message-driven" microservices.
The text was updated successfully, but these errors were encountered:
https://youtu.be/DzGuDNHsOQ0
"Events" have recently been given a lot of attention as a very powerful means of communication between components. They pop up almost everywhere in different shapes and forms, and for different reasons. Unfortunately, they often completely miss their purpose, and instead of decoupling components, they subtly introduce an implicit coupling in logic.
The distributed big ball of mud is born.
Throwing more technologies at it won't solve the problem, all it will do is simply introduce a new layer of mud on top of the old.
In this session, I will take a few steps back and look at three reasons why components need to communicate. I will demonstrate that by considering the reason of the communication, you can select suitable routing patterns, choose an appropriate protocol and technology to transport each type, and end up with proper decoupling of components. This decoupling means that it doesn't matter anymore whether the messages are handled in the same process as the sender, on different hosts or even in different data centers altogether. This so-called location transparency then becomes a big enabler for building evolutionary "message-driven" microservices.
The text was updated successfully, but these errors were encountered: