5 ms·
Containers, like static linking, protect you from someone else’s platform if you can’t rely on it. But if it’s your own platform, why can’t you rely on it? Who’
by erik_seaberg 3y ago
Containers, like static linking, protect you from someone else’s platform if you can’t rely on it. But if it’s your own platform, why can’t you rely on it? Who’s maintaining it?
- drpixie 3y agoBest summary of containers - clear and hits the point.
- pkulak 3y agoMaybe you just want the ability to run on any platform.
- nailer 3y ago> But if it’s your own platform, why can’t you rely on it? Who’s maintaining it? I don’t know if this is a rhetorical question. You are now responsible for maintaining your custom environment. Obvious reasons why you can’t rely on maintaining your own platform include a lack of time for maintenance, a lack of understanding of the platform you have built, and a lack of prioritisation compared to other requirements. A huge amount of the value that senior admins provide is simply stopping junior and mids from building custom platforms usually because they’re excited about a technology rather than aware of the wider picture.
- WJW 3y ago> a lack of understanding of the platform you have built There is also the common extension to this problem: someone else built this platform some time ago and has long since left the company.
- nailer 3y agoYes exactly! Or “this has a bug, is only understood by one person and he’s busy right now”.
- erik_seaberg 3y agoYeah, when I say “our own platform,” I’m thinking something like “we run Debian bullseye 11.7 in prod, build a .deb for that.” Starting our own unique distro in a Docker container is not a good use of time.