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

31–40 of 71 posts

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

#31

Post by bossyTeacher »

_hl_ wrote: post #10

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…

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

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

#32

Post by ChicagoDave »

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 everything including APIs, data store, commands, and events.

This article is similar to saying all applications should use a relational database or all applications should use AWS Lambdas.

The most important step in any architecture is "It depends."

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

#33

Post by mpweiher »

geomagilles wrote: post #12
mpweiher wrote: post #9

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.

> Without a way to represent the architecture as runnable and testable code

That's what I am working on with Objective-S.

https://objective.st/

The idea is that you can express many more kinds of architectures / architectural-styles directly as executable code.

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

#34

Post by fcantournet »

callamdelaney wrote: post #25
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 quite tedious when discussing kafka people are spouting just the contents of confluent blog posts, like you must use X serialisation, you must use X registry, when in a lot of cases you can just use protobuf.

Whether you use protobuf or avro/cap'n'proto/flatbuffers has little to no bearing on whether you need a registry for schemas.

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

#35

Post by fcantournet »

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…

I like this choregraphy inside a domain, orchestration across domains rule of thumb. I think it maps to what we did a few years ago at previous enployer (without actually formalising like this).

Some cross-domain things are inherently orchestration problems (like GDPR deletion)

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

#36

Post by exe34 »

bossyTeacher wrote: post #31
_hl_ wrote: post #10

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…

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!

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

#37

Post by SillyUsername »

Isn't this the same as AWS step functions?

Maybe I missed the party trick but under the hood a step function definition will be orchestrated between lambdas (the services).

The only difference to this pattern is you define event inputs and outputs on the service, as part of orchestration, which I feel is absolutely needed to know by consuming services (why wouldn't you, unless you're hoping to avoid object versioning / changes clashes of services by doing that, which is better served by you know, actual versioning tags...).

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

#38

Post by happymellon »

somat wrote: post #27
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.

pedantic note. nobody talking about REST really does REST. Where is the representational state. REST is when you ship the whole application in the message to the far side to let them figure it out. Now that I've got that stupid pedantry off my chest, Yeah I know what you mean when you say REST we all know what is meant when REST is brought up. But I find it funny how Roy Fielding said "wow, it is really cool how web…

On the one hand I could go

> Ah ha, but we don't use REST that's my complaint!

But you are correct, although I have used representational state through the request in this case I'm just talking about using a message bus Vs using a blocking http call.

Additional annoyance, using inappropriate tech means that we can't even do scaling to handle spikes. Having a Kafka rebalance because traffic is a little higher so I need to increase the number of listeners and cause an outage when I actually need more throughput makes me sad.

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

#39

Post by thaumasiotes »

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 performances. But I strongly suspect that the difference between auditory and visual display isn't what you're supposed to get out of this terminology. How am I supposed to remember which approach is which?

Neither orchestration nor choreography involves agents reacting to other agents; there's an objective clock and everyone takes their cues from that.

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

#40

Post by binary132 »

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…

People need to dream up new jargon to get other people to feel like their design patterns are “official”, I guess. I was wondering the same thing. It seems pretty arbitrary.
Post reply on HN