That’s what companies hire for. I’ve learned those skills and no one ever really wants them.

If you build tools with that context, they’ll have to replace you with someone that has that context. There’s few of them, and they’re expensive.

It’s easier to hire folks that should be interns or juniors that know that one tool, and then replace the whole department every decade.

It’s why everything is YAML now, despite it being horribly verbose and clunky. Can’t have our people needing to know how load balancing works, just add another 95 lines of YAML boilerplate so they don’t need to learn 5 lines of nginx config.

▲

JimBlackwood 6 hours ago | parent [-]

I never understand this sentiment. I do SRE/DevOps/Platform Engineering/Infrastructure Engineering, and I definitely do need to know how underlying technologies work. Even when everything is kubernetes and YAML.

If you run simple workloads, it’s probably not necessary but then you’ll probably be paid for that. Your company can also choose to outsource complexity to the cloud, and you’ll just be writing YAML. Then there’s also companies where you host everything yourself AND you have large/high workloads, then you still need people with understanding.

With your type of comments, it feels like you’re pretending a developer who writes WordPress websites does the same work as someone doing Erlang for instance. You’ll have different skill sets for every type of engineer, and they’ll all be necessary.

	▲	everforward 5 hours ago \| parent [-]
		I also work in the space. I think you’d be surprised if you look at the younger (post-2000-ish) companies. Specifically about this part: > If you run simple workloads, it’s probably not necessary but then you’ll probably be paid for that. You would be surprised how many workloads either are simple, or can be ham-fistedly shoved into a “simple” architecture. Eg I’ve seen a lot of Postgres-on-k8s solutions that are basically just Postgres on bare metal with a bunch of useless abstractions. It writes to local disk, moving the pod to a new host is basically restoring from backup. Wrap it in some tool that ingests YAML and call it a day. k8s is sort of the king of this. I hear people say they understand k8s and I can’t help but furrow my eyebrows. I don’t even pretend to, there are so many insanely complicated edge cases. Eg if I’m sending UDP packets to a service and scale the deployment from 2 pods to 4 and the host for one of the new pods crashes and comes back up with a bad iptables rule, what are the range of potential behaviors k8s would show? What’s the difference between blocking say all traffic vs only traffic to one or two of the etcd instances? What if it’s blocking half the hosts in the cluster? Storage has its own weird vagaries around single vs multi mounts and race conditions therein. k8s is the king of “I don’t have to know that, the platform will do it”. I’m not sure I’ve ever heard anyone outside networking talk about whether a pod will saturate a NIC. Just chuck it in the cloud and let it figure itself out.