5 ms·
Disagree with distributed monolith. It's a big team/small team thing. We converted a big monolith batch processing application to streaming + Kafka using what
by __jem 6y ago
Disagree with distributed monolith. It's a big team/small team thing.
We converted a big monolith batch processing application to streaming + Kafka using what might be described as a distributed monolith and it worked great.
Using a single framework abstraction (in this case Spring) helps eliminate a huge amount of incidental complexity. We don't want teams inventing their own ways to manage things like retries, topic creation / administration, dlq, partitioning,...
If I wasn't using Spring/Java, I'd be using Elixir for similar reasons. Frameworks are good for async/distributed programming.
If you work in big tech and have enormous amounts of resources to throw at it, sure, go with totally independent microservices. But, distributed monolith can be very productive and provide a significantly easier mental model.
- linkdd 6y agoErlang/Elixir is a bad example because much of the microservice best practices come from (IMHO) the actor model implemented with OTP. Put your microservices in a mono-repo, replace "microservice" by "erlang process", replace "orchestration" with "OTP supervisors", and that's it. Conceptually it's almost the same.
- deleted 6y ago[deleted]
- musingsole 6y ago> We don't want teams inventing their own ways to manage things like retries, topic creation / administration, dlq, partitioning,... Then enjoy all the pains of a planned economy-errr architecture