5 ms·
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 h
by buster 2y ago
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.
- callamdelaney 2y agoIt 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.
- fcantournet 2y agoWhether you use protobuf or avro/cap'n'proto/flatbuffers has little to no bearing on whether you need a registry for schemas.
- callamdelaney 2y agoRegistry 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 https://youtu.be/y8OnoxKotPQ?si=D3gBOpPtSqnhgL3b
- karmarepellent 2y agoSo 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.
- fcantournet 2y agoI 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)
- thaumasiotes 2y ago> 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.
- binary132 2y agoPeople 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.
- edudobay 2y agoI 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.
- thaumasiotes 2y ago> 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.
- 2y ago
- thebigspacefuck 2y agoIs medium-driven development an antipattern?
- fullspectrumdev 2y agoA 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?
- Cthulhu_ 2y agoMedium-driven development is neither rare nor well-done.