4 ms·

Who says the monolith we had was a clean codebase with a solid toolchain? It was a giant piece of software that had existed since the 90s, with hundreds of deve

by bedobi 6y ago

Who says the monolith we had was a clean codebase with a solid toolchain? It was a giant piece of software that had existed since the 90s, with hundreds of developers working on it at any given moment, thousands of people coming through it over the years, full of bizarre things that would make anyone scream and tear their hair out. (each of which may have been the right thing to do at the time, but combined over the years wasn't optimal to say the least) It's obvious nothing will convince you, but I maintain that eg internal vacation hours should not live in the same codebase as partner facing business critical things.

robertlagrant 6y ago
> Who says the monolith we had was a clean codebase with a solid toolchain? You didn't. They're just trying to force the issue for some reason by straw manning your decision.
Nextgrid 6y ago
You can very well have a bad monolith and still think micro services is a bad idea, and his concerns especially around referential integrity are perfectly valid and valuable. Maybe all you needed is to fix the existing monolith incrementally?
- bedobi 6y ago
  Of course microservices should be sliced with referential integrity in mind. But a monolith by definition has everything, including utterly unrelated things that have absolutely nothing to do with each other, bundled up into a single, giant, well, monolith. What referential integrity could there possibly be between eg business partner user profiles and internal staff vacation hours?
  - quickthrower2 6y ago
    There is nothing inherently bad about storing unrelated things in the same db, in general. There might be security issues but good DBs offer security grants that are granular enough to deal with this. Data sovereignty might be an issue forcing you to split, that depends on the domain and application requirements. But in general two things being unrelated isn’t a reason to split the DB and splitting the DB isn’t a reason to split into services. I’m not for or against microservices. I’m definitely for good reasoning though!

by bedobi 6y ago

robertlagrant 6y ago

> Who says the monolith we had was a clean codebase with a solid toolchain? You didn't. They're just trying to force the issue for some reason by straw manning your decision.

Nextgrid 6y ago

You can very well have a bad monolith and still think micro services is a bad idea, and his concerns especially around referential integrity are perfectly valid and valuable. Maybe all you needed is to fix the existing monolith incrementally?

bedobi 6y ago
Of course microservices should be sliced with referential integrity in mind. But a monolith by definition has everything, including utterly unrelated things that have absolutely nothing to do with each other, bundled up into a single, giant, well, monolith. What referential integrity could there possibly be between eg business partner user profiles and internal staff vacation hours?
- quickthrower2 6y ago
  There is nothing inherently bad about storing unrelated things in the same db, in general. There might be security issues but good DBs offer security grants that are granular enough to deal with this. Data sovereignty might be an issue forcing you to split, that depends on the domain and application requirements. But in general two things being unrelated isn’t a reason to split the DB and splitting the DB isn’t a reason to split into services. I’m not for or against microservices. I’m definitely for good reasoning though!