> performance/flexibility/scaling of microservices
Tiny microservices tend to perform and scale poorly due to their granularity.
Fully agree. Unless the strict granularity is needed, which it's usually not, services should align to the tasks that the upstream "user" needs to accomplish. If every task requires calling the same 4 microservices in sequence, you've done it wrong. At the very least, the granularity should exist only where it's needed.
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.
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.
Then enjoy all the pains of a planned economy-errr architecture