Just philosophical. I'm honestly not sure which approach I like more after having done it both ways: highly isolated projects (open source world, at Amazon), and monolithic (at Google).
It all boils down to dependency management in the end.
---
For the monolithic world:
* You're always developing against the latest version of your dependencies (or very near it).
* This comes at the cost of a continuous, but minimal, maintenance burden as upstream folk make changes.
* * However, because things are monolithic, upstream projects can change _your_ code, as well. You can be confident that you know exactly who is affected by your API change.
* * Similarly, being able to make an API change and run the tests of _everyone that depends on you_ is a huge benefit.
* You have to be more diligent when testing things that go out to users, as your code is constantly evolving.
---
For the isolated world:
* You can develop without fear of interruptions; your dependencies are pinned to specific versions.
* You get to choose when to pay the cost of upgrading dependencies (but typically, the cost is pretty high, and risks introducing bugs).
* * Security patches can be particularly annoying to manage, though (if you let your dependencies drift too far from current)
* During deployment, you can be extremely confident about the bits that go out.
* You can get away with less rigorous infrastructure (and maintenance costs related to that)
It all boils down to dependency management in the end.
---
For the monolithic world:
* You're always developing against the latest version of your dependencies (or very near it).
* This comes at the cost of a continuous, but minimal, maintenance burden as upstream folk make changes.
* * However, because things are monolithic, upstream projects can change _your_ code, as well. You can be confident that you know exactly who is affected by your API change.
* * Similarly, being able to make an API change and run the tests of _everyone that depends on you_ is a huge benefit.
* You have to be more diligent when testing things that go out to users, as your code is constantly evolving.
---
For the isolated world:
* You can develop without fear of interruptions; your dependencies are pinned to specific versions.
* You get to choose when to pay the cost of upgrading dependencies (but typically, the cost is pretty high, and risks introducing bugs).
* * Security patches can be particularly annoying to manage, though (if you let your dependencies drift too far from current)
* During deployment, you can be extremely confident about the bits that go out.
* You can get away with less rigorous infrastructure (and maintenance costs related to that)