5 ms·

Ex-Amazon SDE here: SOA is good, team boundaries are good, tiny microservices are bad, distibuted monolith is really bad. > performance/flexibility/scaling of

Ex-Amazon SDE here: SOA is good, team boundaries are good, tiny microservices are bad, distibuted monolith is really bad. > performance/flexibility/scaling of microservices Tiny microservices tend to perform and scale poorly due to their granularity.

fatnoah 6y ago
>Ex-Amazon SDE here: SOA is good, tiny microservices are not. 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.
__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 ago
  Erlang/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

fatnoah 6y ago

>Ex-Amazon SDE here: SOA is good, tiny microservices are not. 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.

__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 ago
Erlang/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