Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Way We Are Building Event-Driven Applications Is Misguided

gillesbarbier.medium.com

Post reply on HN
Print view View original

41–50 of 71 posts

Re: The Way We Are Building Event-Driven Applications Is Misguided

#41

Post by inkyoto »

happymellon wrote: post #13

My current situation is that I'm having to work with an event driven architecture for a strictly synchronous process. 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.

Hear, hear. A few years ago I worked for an esteemed client whose director said «I want Kafka» for [mostly] synchronous interaction patterns. I said «no», the director said «I want Kafka». That repeated a few more times, and I had to begrudgingly comply since the client was paying for it.

The architecture for the solution drew the inspiration pretty heavily from the TCP protocol design, with incoming events yielding either an ACK or a NACK events also dispatched asynchronously. The key was the stringent adherence to supplying the original event ID in the Reply-To event envelope (hello, SMTP) and having a separate process correlating the inbound and outbound ACK/NACK events. It has wrought success in times bygone (and does persist unto this present day), yet I must, with all due deference, decline to partake therein henceforth.

Re: The Way We Are Building Event-Driven Applications Is Misguided

#42

Post by Waterluvian »

ChicagoDave wrote: post #32

This completely leaves out the business model, which should always be the driving force behind any architectural decisions. I don't know what type of cross-domain communication I need until I model something. Any given domain could have many published events. Any given domain could have many commands. Any given domain could have many subscriptions. The business models of those domains come first. That dictates everyt…

This is key and it’s something engineers constantly miss. My best guess is because it involves a lot of the stuff that engineers don’t find interesting or require outside help with from the business side of the company.

But I’d say almost all of the interesting and challenging parts of engineering happen here. The rest is just manufacturing and maintenance. (Though I find those fun too!)

Re: The Way We Are Building Event-Driven Applications Is Misguided

#43

Post by orthoxerox »

I think extensive orchestration leads to the orchestrator becoming a single point of failure. If the orchestrator starts converting events to commands then soon it starts storing state and becomes a big ball of mud.

My preferred form of orchestrator is a gatekeeper. A gatekeeper does three things only:

- maintains a table of which service consumes which events and why - copies events from the outgoing queues to the dedicated incoming queues according to the routing table (or controls access to the incoming queues via RBAC) - logs the metadata about the messages it has seen

It doesn't inspect the messages in any way, store them or maintain any runtime state at all.

Re: The Way We Are Building Event-Driven Applications Is Misguided

#44

Post by edudobay »

thaumasiotes wrote: post #39
buster wrote: post #23

Be aware of marketing blog posts like this (looking at you Confluent, Databricks and Camunda!). Another "forget this style, only use our new framework". What he forgets to mention, and what is probably not in the scope of "our new framework that does everything better", is that it is totally valid to use orchestration and choreography. Same as Confluent pushes the case to use choreography, this post pushes to just us…

> it is totally valid to use orchestration and choreography. Same as Confluent pushes the case to use choreography, this post pushes to just use orchestration. What's the metaphor here? As far as I can see, orchestration is about coordinating the timing of several simultaneous and interdependent musical performances, while choreography is about coordinating the timing of several simultaneous and interdependent dance…

I think the analogy is clear when I think of it as: - Orchestration brings the idea of a conductor, who is the main reference for "what should we do" among orchestra players. - Choreography brings the idea of dancers in sync without the need of a central conductor.

Re: The Way We Are Building Event-Driven Applications Is Misguided

#45

Post by buster »

thaumasiotes wrote: post #39
buster wrote: post #23

Be aware of marketing blog posts like this (looking at you Confluent, Databricks and Camunda!). Another "forget this style, only use our new framework". What he forgets to mention, and what is probably not in the scope of "our new framework that does everything better", is that it is totally valid to use orchestration and choreography. Same as Confluent pushes the case to use choreography, this post pushes to just us…

> it is totally valid to use orchestration and choreography. Same as Confluent pushes the case to use choreography, this post pushes to just use orchestration. What's the metaphor here? As far as I can see, orchestration is about coordinating the timing of several simultaneous and interdependent musical performances, while choreography is about coordinating the timing of several simultaneous and interdependent dance…

Orchestration needs an orchestrator, choreography does not.

Re: The Way We Are Building Event-Driven Applications Is Misguided

#46

Post by robertlagrant »

My job a while ago was doing business process automation with webMethods[0].

It had some flaws, of course, but the general idea was you drew business processes in a UI tool (or wrote the corresponding code that generated the process, but drawing was easier) and the process was then implemented into messages queues/topics and different types of integrations as part of the deployment process.

Because it was standardised, you could plug in a product that visualised processes, showed where bottlenecks were, let you restart failed ones, etc. In retrospect it was pretty advanced.

[0] https://www.trustradius.com/reviews/webmethods-business-proc... - sorry for the puff piece link but the corporate website is so bad

Re: The Way We Are Building Event-Driven Applications Is Misguided

#47

Post by lelanthran »

buster wrote: post #45
thaumasiotes wrote: post #39

Earlier quoted context omitted.

> it is totally valid to use orchestration and choreography. Same as Confluent pushes the case to use choreography, this post pushes to just use orchestration. What's the metaphor here? As far as I can see, orchestration is about coordinating the timing of several simultaneous and interdependent musical performances, while choreography is about coordinating the timing of several simultaneous and interdependent dance…

Orchestration needs an orchestrator, choreography does not.

> Orchestration needs an orchestrator, choreography does not.

That analogy doesn't make sense to me.

An orchestra can play a piece without a conductor.

Choreography has an "orchestrator" for all but the final performance.

Neither can work indefinitely without a director, while both can work for a single performance without a director.

So it's still not clear to me what the difference is supposed to be.

Re: The Way We Are Building Event-Driven Applications Is Misguided

#48

Post by lelanthran »

exe34 wrote: post #36
bossyTeacher wrote: post #31

Earlier quoted context omitted.

Some things never change. Devs calling "any pattern or code they dislike" spaguetti is one of them. Just like "clean".

Any code you didn't write today is legacy code!

> Any code you didn't write today is legacy code!

Any code you didn't write is legacy code!

Re: The Way We Are Building Event-Driven Applications Is Misguided

#49

Post by HelloNurse »

It seems mostly a new rug to sweep complexity under, not necessarily in better ways.

For example, "built-in observability of workflows states" seems to imply very invasive constraints on workflow/orchestrator implementations: maybe a net positive, but contrary to the promise of an "easy way to implement your business logic in full Java".

Re: The Way We Are Building Event-Driven Applications Is Misguided

#50

Post by thaumasiotes »

edudobay wrote: post #44
thaumasiotes wrote: post #39

Earlier quoted context omitted.

> it is totally valid to use orchestration and choreography. Same as Confluent pushes the case to use choreography, this post pushes to just use orchestration. What's the metaphor here? As far as I can see, orchestration is about coordinating the timing of several simultaneous and interdependent musical performances, while choreography is about coordinating the timing of several simultaneous and interdependent dance…

I think the analogy is clear when I think of it as: - Orchestration brings the idea of a conductor, who is the main reference for "what should we do" among orchestra players. - Choreography brings the idea of dancers in sync without the need of a central conductor.

> Choreography brings the idea of dancers in sync without the need of a central conductor.

Try that and let me know how it works.

In reality, the dancers are of course synced by the music, dependent on the same conductor as the orchestra.

And on top of that, orchestration isn't the conductor's job. It's the composer's (or arranger's) job, putting it exactly parallel to choreography. The orchestrator, like the choreographer, determines who does what and when they do it, and he does it in advance. Most typically, years or centuries in advance. The conductor determines how fast the clock runs.

Post reply on HN