| 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) |