Hacker News Reader

Comment by GordonS | Hacker News Reader

Playing Devil's advocate here, but there are some good reasons you might do this. For example, Docker's "pull" system is great for updates, and means it's trivial to rollback to an earlier version if something went wrong. A Docker registry also means you can easily switch to another version when needed. You also get a supervision of containers, with automatic restarts (yes, I know you can do this nowadays with systemd :)

View on HN

Sure, but if you provide the possibility to deploy a lot of components separately, at some point they will run in different versions. And who knows if rear view camera 1.3.22-44 works with turn signal 4.86.233-stable and break pedal 0.6.9876-beta?

How is that different from shared libraries?

It’s the same problem. But library authors usually take extra care to stay compatible.

And if you create your own shared libraries, they are normally not deployed separately, usually you bundle them with your main executable.

Shared libraries are bundled into one container, then the one container is submitted to a gauntlet of tests (service / API-level tests, e2e tests, etc.).

If you're submitting an embedded device to a gauntlet of tests, you're anyway "containerizing" all the shared libraries when you build the embedded image. Trying to build containers within the embedded image has questionable merit.

Because you can prove it. In the auto industry you can't just claim it conforms, you have to prove it does for all possible conditions. With containers enforcing that separation, you can prove it much more easily.

Those 3 for the most part don't have to work together. They need to run on the same CPU without taking more than their allowed portion of the CPU.

If they have to work together the communication protocol is clearly defined well in advanced and limited to exactly what they need to say. Thus we are reasonably sure if any one combination works all possible combinations will work. Even then there is typically higher level control to only release combinations that are tested to work together.

That sounds good in theory. The reality I live in, is different though. If it works for you, that’s great!

A statically compiled executable is even easier, and can be hosted on your webserver

But unfortunately they also become very space inefficient when a lot of processes need the same (relatively) large blocks of code. But if you carefully curate your containers to use the same base image that contains those libraries already, you don't have to duplicate it.

Comparable would be to having an inode de-duplicating file systems, and deterministic binary generation. But it's hard to prove "the correctness" of inode de-duplicating file systems in extreme environments like auto is required to, and deterministic binary generation is hard to control 3ven if it is possible with the specific build tools (it usually isn't).

Yup, I can imagine complete images are easier to version-manage and to tag as minor/major/hotfix than each individual part of the stack.

I think people underestimate the amount of software that is ALREADY running in their cars/airplanes/helicopters and even elevators.

"yum", "apt" etc have registries, roll back etc and have for a good few decades.

This forced application of new technologies into every possible domain can have real security and reliability consequences - and all because some VP somewhere decided they needed to use the latest shiny thing in cars or fridges or ACs or whatever.

Imagine we could build a dishwasher that didn't throw water on the floor?

Oh well, we got WiFi instead. That's fun, right?

If a dishwasher needs a firmware update, I might simply argue it was defective. Not everything needs to be secure or updated constantly. It shouldn't have network access to begin with.

Exactly. When will vendors stop touting WiFi access as a "feature"?

And when you upgrade ssl lib now 200 apps are not vulnerable to exploit, vs updating 200 different containers

unless the update requires version updates on multiple services which means the versioning and rollback has the same effect as a more monolithic codebase. but with the added complexity of not knowing how it all impacts each other.

In my experience updates to smaller services are often trivial, or for updates that are actually impactful it would be way easier to coordinate in a monolithic codebase.

yes my first job over 15 years ago was essentially micro services, and we ran into this type of problem..

trivial updates to individual services could be iterated extremely quickly

systematic changes to behavior across services were so hard they became incredibly uncommon

Reply on news.ycombinator.com