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

21–30 of 71 posts

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

#21

Post by geomagilles »

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.

Indeed. Using a streaming platform makes sense only if you need messages durability (and sometimes reusability). When implementing a request/reply pattern on top of such a platform (Infinitic does that btw), it necessarily adds some latency due to multiple persistence operations.

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

#22

Post by lll-o-lll »

noncoml wrote: post #18

Building highly available Rick solid software is extremely difficult and expensive. The advantage of Kafka is that we can use a well known battle tested solution as our backbone and write buggy software around it.

Rick solid software is very dependent on the quality of your Rick.

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

#23

Post by buster »

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 use orchestration.

That's wrong. From my point of view:

  1. use choreography for small to medium services (for example one domain)
  2. optionally orchestrate them on a higher level (for example between domains)
Don't orchestrate all your business logic for all services down to the smallest event/command!

Also: You don't *need* to store all your events forever. This pattern, often pushed, comes with downsides as well. Maybe you have a good case to do so, but don't fall into the trap to just use this pattern because you've read that in some blog post!

Alternatively, you can also just go the route of those vendor blog posts and pay later for the lock in.

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

#24

Post by dualogy »

geomagilles wrote: post #19
_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…

Thank you for your comment. Highlighting the need for a descriptive format to orchestrate services implemented in multiple languages is a valid point. While Infinitic currently uses Java's interfaces, adopting a more generic and language-agnostic solution like Protobuf is a sensible approach that could promote better interoperability across different tech stacks. Then we need a DSL. Again, Infintic is using Java/Kotl…

> Then we need a DSL.

Or perhaps just the data structs already expressible in Protobuf, come to think of it. Versionable and textual thus git/etc-able.

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

#25

Post by callamdelaney »

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.

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

#26

Post by thom »

geomagilles wrote: post #20
thom wrote: post #16

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?

The idea is that each business process can be implemented through its own service. So a microservice architecture is still very relevant from an organisational point of view. The team in charge of this business process must know the interfaces of the services it uses. But they are the only ones. There is actually less coupling in this organisation, not more.

But those services know about each other and have to communicate, right?

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

#27

Post by somat »

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 pages ship the whole application to the user on each request lets talk about that" and everyone else basically went "ok HTTP == REST, got it"

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

#29

Post by karmarepellent »

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…

So it is one thing that you might want to assess if the patterns that were described in the article actually fit your use case and then adopt the one that fits better.

But putting this sentiment to the extreme, you could also say: For very "small" use cases, that is systems where scalability might not be an issue (right now and in the future), you might want to dispense with any kind of distributed system altogether and just program a monolith. Because if you have tightly-coupled parts of a more complex system that cannot really function if at least one is down, you might as well put them in the same program.

Again, the main drawback will be horizontal scalability. But in a small enough company your "process engine" can probably be run a small VM anyway.

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

#30

Post by lll-o-lll »

Hmmm. I think this is interesting, but I’m not sure this is an “architecture”.

A workflow or “orchestrator” as defined in this article looks like another service. Unless I’m missing something, it’s a state-machine where inputs/variables are the events of other services, and where transitions trigger “commands”.

Don’t get me wrong, I see the value in pulling this logic into a central place/process in order to perform “orchestration”, I just don’t see the value in yet another framework. This is a pattern that pops up in every distributed system I’ve worked on, but it is just one of many.

In many cases, a synchronous request response end-point is all that is necessary/desired for a service tied to a customer interaction. In others, a service processing a queue backlog (with or without automatic fan-out). In others publish-subscribe seems the best fit. In others, a more complex state-machine managing several different events, transitions, and outputs.

Can you model everything as a state-machine? Yes. Should you? I would argue that you want a range of tools in the toolbox.

Post reply on HN