Hacker News Reader

Comment by yakshaving_jgt | Hacker News Reader

Ok, interesting. That kind of scale is not exactly the norm though, so I don't agree with your implication that monoliths are always a bad idea.

View on HN

I really don't know why anyone who wasn't so resource strapped as to have no alternative would want their $$$ services sharing a build-test-deploy-rollback lifecycle or database with the internal staff vacation hours tracker.

It seems like the real solution here is to outsource vacation hour tracking to one of the HR apps for the purpose (see Workday) instead of having the domain expert engineers split the company’s application apart into micro services so they can have a custom vacation tracker.

It was just one of the worst examples. A more obvious case would be the different lines of business. They have very little to do with each other and shouldn't share code or data. Another is business partners vs end users (regular people) - there's a lot if reasons, including legal ones, why they shouldn't share code or data.

That makes sense, but is nowhere near universally applicable. For folks working in most startups, talking about different lines of business is non-sensical - there's generally one product.

It sounds like you're describing a monolith that actually contained multiple completely independent applications - which I don't think anyone would disagree with being a good case for splitting.

In most cases I've seen, the decision to split into microservices usually involves a fairly high amount of dependency between different services to achieve a common business goal (hence the concerns about things like referential integrity)

Reply on news.ycombinator.com