Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We achieved a 6-fold increase in Podman startup speed

redhat.com

Post reply on HN
Print view View original

31–40 of 196 posts

Re: We achieved a 6-fold increase in Podman startup speed

#31

Post by steveBK123 »

interactivecode wrote: post #15
GordonS wrote: post #5

Earlier quoted context omitted.

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 system…

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

Re: We achieved a 6-fold increase in Podman startup speed

#33

Post by ilyt »

zokier wrote: post #24
andix wrote: post #6

Earlier quoted context omitted.

I agree. Microservices are a great concept for a lot of problems. But now I constantly see way too small services. Every tiny piece of software gets its own service and its own software lifecycle (including versioning and deployment). And what happens now is, that you need a huge effort to integrate all those components. End to end system tests get much more important, but are still harder to do than simple unit/inte…

You are blaming cultural issues on technology. You have the same integration pains with libraries too. In general if your teams are not aligned, it doesn't really matter if they are developing microservices, libraries, or one spaghetti ball mess, its going to be problem anyways

The old method of forcing everyone to freeze at certain dependencies also means that any bug in those dependencies is fixed in all components at once.

Obviously going too big here is problematic as it can slow it down when tens or hundreds of people are involved in every update, but going too small have similar problems, on top of generally more smaller services eating more resources. We don't need "front reflector LED setting app" being called from "lighting setting app" called from "car setting app", it can probably just be one service.

Smaller services also mean more services to update if some commonly used lib gets a security bug. Updating SSL lib in big monolith is just update, run tests, but in microservices that's multiplied by amount of teams and services.

> In general if your teams are not aligned, it doesn't really matter if they are developing microservices, libraries, or one spaghetti ball mess, its going to be problem anyways

Moot point. We pick the tools to make the job easier. Good team with bad tools will still be slower and less efficient than good team with good tools.

Re: We achieved a 6-fold increase in Podman startup speed

#34

Post by ilyt »

rwmj wrote: post #10
GordonS wrote: post #5

Earlier quoted context omitted.

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 system…

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

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

Re: We achieved a 6-fold increase in Podman startup speed

#35

Post by solatic »

wiseowise wrote: post #13
andix wrote: post #8

Earlier quoted context omitted.

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?

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.

Re: We achieved a 6-fold increase in Podman startup speed

#37

Post by spyremeown »

rwmj wrote: post #3

> If the backup camera or other sensors were to run as containers, we needed to improve the starting speed significantly. I think I see the problem already. Why does anyone think its a good idea to put everything in an embedded system into a container? Particularly as everything comes from a single vendor and so the usual argument about "but libraries are too hard!" doesn't apply.

https://www.toradex.com/torizon they do and it works quite well. Super handy to have CI/CD and easy OTA updates with containers.
Post reply on HN