[_6pvr]

> Most devs have to know the commands and configuration to do rolling deployments on the target infrastructure, fetch logs, how the readiness protocoll integrates with automatic restarts, ingress, etc.

Is this serious? You think _most devs_, meaning a group that includes FE devs, mobile app devs, IoT, open source, DBAs, security engineers, need to know these things?

> With k8s, all this is standard and transferable. With ad-hoc simpler solutions, this is all per-team tribal knowledge, and in my experience it's not even simpler to use for us devs.

Most teams do not have to manage most/all of the things you're describing.

This really feels like more K8s marketing disguised as a HN post.

[marvelous]

Yes, it's serious for _most devs_ who have code that could run on k8s: back-end devs. And _most_ devs who touch anything in FE, mobile apps, IoT, DBAs also have to touch the corresponding back-end and its associated platform tooling where k8s is a bliss compared to all the team-specific stuff we encounter in the back-end. Now I agree that k8s is a nightmare for the infra people who run it, but honestly it is insanely comfy for the (back-end) devs who need to use it.

[void_mint]

> Yes, it's serious for _most devs_ who have code that could run on k8s: back-end devs

What an impactful little nuance to leave out of all previous conversation :)

> And _most_ devs who touch anything in FE, mobile apps, IoT, DBAs also have to touch the corresponding back-end

I do not agree with this statement at all. If your org is large enough to use K8s at scale, your mobile devs aren't touching your infra. Being aware that infra exists is not the same as modifying and managing infra.

> Now I agree that k8s is a nightmare for the infra people who run it, but honestly it is insanely comfy for the (back-end) devs who need to use it.

If your BE devs involvement in K8s is cloning a repository that may or may not contain a directory of k8s config that they never open, yes.