11–20 of 71 posts
Very interesting! You write: There is no easy way to understand how a specific business process is actually implemented. The whole process is defined by how each service reacts to others. There is no central repository, and the implementation details of business processes are scattered everywhere. Yes, indeed. There is no easy way because the total system architecture is implicitly defined by the interactions of the…
Buzzword architecture is awful, and having Kafka offer fake design patterns to reassure naive architects, such as a request/reply with small response timeframes.
Attempting to replicate REST with overcomplicated overhead.
This is the biggest issues I encounter with event driven applications.
Earlier quoted context omitted.
Can you access through this url? https://gillesbarbier.medium.com/the-way-we-are-building-eve...
Negative, either that url or incognito for me.
In this article, I express that the prevalent approach to building event-driven applications using the choreography pattern is misguided and can lead to significant technical debt. As an alternative, I introduce the Infinitic framework as a way to enable teams to implement event driven processes without the pain and complexity of building and managing an event-driven system themselves.
Shame it’s on Medium, so I immediately get a paywall / ad, and don’t end up reading your post.
Very interesting! You write: There is no easy way to understand how a specific business process is actually implemented. The whole process is defined by how each service reacts to others. There is no central repository, and the implementation details of business processes are scattered everywhere. Yes, indeed. There is no easy way because the total system architecture is implicitly defined by the interactions of the…
Indeed. And you are raising another good point: the testability of such architecture is quite poor. Without a way to represent the architecture as runnable and testable code, it is problematic to ensure the correctness and reliability of the system. While documentation helps, it does not provide the same level of assurance as testable code.
The advantage of Kafka is that we can use a well known battle tested solution as our backbone and write buggy software around it.
I strongly agree with the premise that an orchestrator-centric approach is preferable to event spaghetti for a lot of business process use cases. Another (maybe more mature) alternative to Infinitic is Camunda, who have been pushing this rhetoric for over a decade. My problem with both is that neither feel very modern, in the sense that they are tied to (in Infinitic's case) or strongly favor (in Camunda's case) Java…
These just seem like sagas, but with the drawback that you now have an additional service for every saga (so now you have N+M problems?) Also if you centrally own all business processes, why did you land upon a microservices architecture in the first place?