3 ms·

This articles makes the assumption that features are easier to develop if subsystems are broken up into separate components, with separate data sources and depl

This articles makes the assumption that features are easier to develop if subsystems are broken up into separate components, with separate data sources and deployments. But experience shows that this is only sometimes the case. Monolithic applications with a big SQL engine as the backend have the advantage that you can do joins very easily. If the data is split into three microservices, you spend much more time thinking about how to do the these cross-service joins more efficiently, narrowing down the amount of data you have to fetch from the other services and so on. People argue that cross-service joins should not be necessary, but that's also easier said than achieved; in reality, they tend to show up, no matter how carefully you partition the services.

amelius 11y ago
I guess that not just the joins become more difficult in a partitioned system, but especially transactions. Maintaining transactional consistency across multiple services seems to me like a nightmare. Even writing tests that address consistency could be very difficult.
- virmundi 11y ago
  Often you don't worry about transactions across services. I know that someone will say we have to have them. In such cases, fine worry about them. In everything else, either isolate the write side of a transaction in one service or don't require them.
  - paulddraper 11y ago
    "don't require them".... Transactionlity is principally dicated by the requirements to the architecture design, not the other way around. " isolate to one service " Yep, a single service with a single database, as mentioned. My point here, like the earlier one, is that there are a lot of situations where multiple services don't fit the domain. In fact, very many, given the extreme complexity around transactions.
- deleted 11y ago
  [deleted]
- jimbokun 11y ago
  And it's not a coincidence NoSQL systems often punt on joins and transactions in order to scale. Both are really hard to make both correct and efficient in a distributed environment.
merb 11y ago
Also this article isn't as good as it could be. too much happiness about micro services. Microservices makes more sense in a bigger team than in a small team. A small team can't work really easily with a codebase that is splitted too much (and with small I mean less than 10). A startup should ALWAYS start with a dumb monolith

amelius 11y ago

I guess that not just the joins become more difficult in a partitioned system, but especially transactions. Maintaining transactional consistency across multiple services seems to me like a nightmare. Even writing tests that address consistency could be very difficult.

virmundi 11y ago
Often you don't worry about transactions across services. I know that someone will say we have to have them. In such cases, fine worry about them. In everything else, either isolate the write side of a transaction in one service or don't require them.
- paulddraper 11y ago
  "don't require them".... Transactionlity is principally dicated by the requirements to the architecture design, not the other way around. " isolate to one service " Yep, a single service with a single database, as mentioned. My point here, like the earlier one, is that there are a lot of situations where multiple services don't fit the domain. In fact, very many, given the extreme complexity around transactions.
deleted 11y ago
[deleted]
jimbokun 11y ago
And it's not a coincidence NoSQL systems often punt on joins and transactions in order to scale. Both are really hard to make both correct and efficient in a distributed environment.

merb 11y ago

Also this article isn't as good as it could be. too much happiness about micro services. Microservices makes more sense in a bigger team than in a small team. A small team can't work really easily with a codebase that is splitted too much (and with small I mean less than 10). A startup should ALWAYS start with a dumb monolith