Hacker News Reader

Comment by fyi1183 | Hacker News Reader

That sounds wrong.

First of all, backwards compatible changes in libraries don't need application updates, by definition.

Second, if your library changes are backwards compatible, you can maintain separate release cycles - this is the normal way of doing things, actually.

Third, microservices simply don't allow backwards incompatible changes. This is a big hint that perhaps your libraries shouldn't do backwards incompatible changes either, as a matter of policy, even though doing them is theoretically possible.

Perhaps you meant deployment instead of releases, and were assuming static linking?

View on HN

Probably what the parent post means by "backwards compatible changes" is that the app doesn't need any changes to use the new behavior of the library, but it needs to be rebuilt/repackaged/redeployed to get that new behavior.

An often seen scenario is that small changes (a one-line bug fix, a tweak in behavior) in application functionality happen to be in the shared library code, so to get that fix to production, you need to redeploy all apps after the library change. Microservices allow you to redeploy just that single shared service.

> happen to be in the shared library code, so to get that fix to production, you need to redeploy all apps after the library change

Doesn't this simply mean that the deployment process is somewhat broken?

On a typical Linux distro, you run "apt-get" or "yum" to upgrade your Heartbleed-fixed OpenSSL, the package manage automatically restarts all affected daemons, and you're done with it.

Even if you deploy static images, a good build system should just re-run the linker after the library change and be done with it.

We seem to be talking about quite different things - in the context of discussion about monolith vs microservice architectures, the expected (at least to me) context is deployment of in-house applications within an enterprise.

This means that even on Linux distro's the packages generally are not managed by apt-get or yum. This means that "shared libraries" don't necessarily mean Linux/C shared libraries, but are likely to be packages of Java/PHP/C#/whatever code that are re-used by multiple applications. This means that, for starters, you need to choose when and how you'll push this update to many different machines each running different applications. This means that "automatically restarting all affected daemons" isn't trivial - some of these services may have state (e.g. a deployment that also includes a change to a database), for some of them the downtime matters, you likely don't want to stop&restart all of the instances doing the same thing at once but rather do a rolling deployment. This means that some of the instances that need to be updated are out of your control/administration - you need to send the package to some other organization so that they can re-deploy it. Etc, etc.

Sure, a good build system should just re-run the linker after the library change and be done with it - that solves the packaging part. Deployment often is much trickier; some organizations have a good, robust deployment process but many (most?) don't.

In my experience, projects which try to follow that strategy inevitably end up with a handful of core libraries containing 90% of active development. The incentive gradient doesn't work; if a project is time-sensitive, the developer just won't agree to do twice as much work to maintain separation of responsibilities.

Reply on news.ycombinator.com