3 ms·

Publicly listed, ~13 billion USD revenue, 22k employees, millions of b2b partners and users. When the monolith goes down, it's hundreds of thousands, sometimes

by bedobi 6y ago

Publicly listed, ~13 billion USD revenue, 22k employees, millions of b2b partners and users. When the monolith goes down, it's hundreds of thousands, sometimes millions of dollars of revenue lost both during and as a result of an outage. You really, really don't want a problem with eg internal staff vacation hours to do that.

yakshaving_jgt 6y ago
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.
- dodobirdlord 6y ago
  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.
  - mrgordon 6y ago
    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.
    - bedobi 6y ago
      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.
      - ryanbrunner 6y ago
        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)

by bedobi 6y ago

yakshaving_jgt 6y ago

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.

dodobirdlord 6y ago
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.
- mrgordon 6y ago
  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.
  - bedobi 6y ago
    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.
    - ryanbrunner 6y ago
      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)