Comment by buster | Hacker News Reader

Comment by buster | Hacker News Reader

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.

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.

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

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.

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.

Interesting. A counter example, WWE (wrestling) is choreographed. The wrestlers react to the cues of the other wrestlers. It's not necessarily based on time or music, but instead a pre-agreed sequence.

I think the catch is that not all cues need to be time based and that is the distinction. In orchestration, there is one source for cues - the orchestrator.

The difference I think speaks to orchestration where the players get their cues from one source, while choreography has different source(s) for cues (time/tempo perhaps being one of them)

> In orchestration, there is one source for cues - the orchestrator.

Just to be clear, everyone's talking about the conductor, who keeps time for the orchestra, but conductors don't do orchestration. The orchestrator is the person who wrote the score.

Good point, for the analogy, I should have written conductor instead of orchestrator. The point remains though that the difference is in the source of synchronization.

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.

Huh? If you don't have a choreographer, you don't have choreography. You have improvisation instead.

Is medium-driven development an antipattern?

A good few years ago when I worked at a security consultancy that catered to a bunch of startups (only some of whom survived long enough to pay the invoices…) we referred to certain development patterns as “HackerNews Driven Development” lol.

I guess Medium driven development is the newer edition of this?

Medium-driven development is neither rare nor well-done.

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)

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.

Registry seems pretty pointless to me, and I can’t understand personally how anyone thought it was a good idea. What was the thought process? ‘oh yeah let’s write a service that our service has to query to work out how to understand the message it just received and which will crash everything if that schema service isn’t there’ - it’s microservices gone mad!

Why worry about what services talk what version of the schema when the service is guaranteed to be able to understand a message?

Reminds me of this: https://youtu.be/y8OnoxKotPQ?si=D3gBOpPtSqnhgL3b

Reply on news.ycombinator.com