3 ms·
I like your point of view. I started working with software more than 20 years ago and did my fair share of VMs, bare metal, ESXi 3.5, and so on. However, we li
by rad_gruchalski 3y ago
I like your point of view. I started working with software more than 20 years ago and did my fair share of VMs, bare metal, ESXi 3.5, and so on.
However, we live in the world where the choice we have for new hires is: a) teach them all of those OS fundamentals, b) give them Docker.
This doesn’t mean we shouldn’t strive to teach said new developers all those underlying concepts, but when we talk about training juniors and have them contribute relatively quickly, it’s a much smaller surface area to bite through.
- saurik 3y agoDocker doesn't solve having to know OS fundamentals as both the inside and the outside of the container have an OS, and now you additionally have to know how to communicate between the former and the latter.
- rad_gruchalski 3y ago> This doesn’t mean we shouldn’t strive to teach said new developers all those underlying concepts That's what I said. Furthermore, let's be pragmatic. The operations team needs to know, yes. We want new hires to contribute and feel productive. They'll naturally learn while working on software. A junior person can contribute almost immediately with a limited surface knowledge. Less friction: no need to understand systemd/upstart/rc what have you, /etc, /opt, /usr, mount, umount, differences between various distros, build-essentials, Development Tools, apt, dpkg, rpm, dnf, ssh keys, ... The right time will come but give them an easy way in. Containers provide exactly that. All they need to know: it's somewhat isolated so under normal circumstances whatever you do in the container doesn't affect the host, how to expose ports, basics of getting your dependencies in, volumes, basic understanding of container networks - for things to talk to each other they need to be in the same network. Enough to start.