[tbronchain]

If they are micro-vms, container-style, I don't think they will have such need to share any library? -in theory, at least- ..

I mean, it is possible to completely isolate them, all.

It may end-up very heavy though, but, and I can be wrong on this, with the constant growth of storage capacities, network bandwidth, RAM capacity, and the progress made to lighten "containers", I don't think this "heavy" downside I see of immutable infrastructures will be a real issue in the future.

[kbenson]

No, but identifying which of your 20 micro-VMs is susceptible to the next OpenSSL exploit, and rolling out the fixes may be. It's both simpler in some aspects and more complex in others to lave local library versions for every app/service. Managing service prerequisites becomes easy and managing service feature updates becomes easier than it was, but managing service security updates becomes more complex. Juggling these different needs and capabilities is where it gets interesting.

[tbronchain]

I got your point.

I guess it just lead to a turning point, where end-users won't have to worry about security updates for x or y library, but more about updating the application they're using. In the case you use containers/micro-vms, if there is a security update to do, the container "maintainer" would be in charge to push the security update, then you just need to update your container.

I'm not sure which one is the most constraining, dealing with conflicts or being careful on relating on well maintained "containers".

I guess, for production environments, the second option looks like a wise choice.