1. 9
  1.  

  2. 2

    This can be good advice, but it depends quite a bit on your goals and needs. If you’re on an engineering team at a large company and your team owns X, any project to improve the state of X — for example, a perf improvement that when rolled out fully will reduce fleet CPU usage by Y% — will have its impact measured by the actual adoption rate of X (i.e. if by the time perf reviews roll around you actually only reduced fleet CPU usage by Y/3 due to slow adoption, the business will reward your team based on Y/3, not Y). What this often in practice boils down to is that after every major improvement to X, you and your teammates will spend weeks or longer chasing down every other team to upgrade to the new version of the library you shipped, because the other teams control your release cycle: you don’t. Whereas with a service, while there is a (typically small) ongoing maintenance cost to your team, you control your own release cycle and can account for improvements as soon as you update your service. So while maintenance cost does exist, it can still be more productive to run the service, because you aren’t wasting time chasing endless upgrades.

    (You can take steps to mitigate this, i.e. failing builds in CI if library versions are too old. But inevitably there will be code for which the proper owners are unclear or have left the company, and you will spend your team’s time and social capital chasing down owners of ancient code that no one wants to own.)

    In practice shipping your code as a service also has some other nice side effects: if there are difficult breaking changes, your team immediately feels the impact, rather than customer teams needing to complain. If there’s a bug, your team’s service is the one firing the alarms and impacted, and your team is generally the most equipped team at the company to fix the bug.

    And perhaps most importantly, if there’s a security vulnerability disclosed, you don’t need to patch the universe to fix it: you upgrade the service.

    Libraries can still be useful of course: common frameworks, protocols, etc. But in practice in my experience at large tech companies, services are less painful to administer than shared libraries. Administering shared libraries is a social problem, which is often harder than keeping a service up, which is an engineering problem (and thus engineers are fairly good at solving it).

    Edit: although the opposite is true for small teams. The coordination cost of telling your friend who sits next to you to bump a version is tiny. Trading a larger ongoing fixed engineering cost to save on nearly free (because your team is small) communication cost is not a good tradeoff.

    1. 1

      This really really needs some CSS to be readable.

      It seems to me that users on an outdated version of the library, even if they are only hurting themselves, are still unhappy users, and nobody wants unhappy users. Plus you still have to support them.