Why does everyone keep thinking developers need to now about K8S? Just be glad if your infra/DevOps/platform teams abstract this away from you and you don't have to deal with this insanity.
if you're at the size of needing K8S, you can afford a devops/cloud engineering team.
To OP's point, this seems to be a trend among corporate blogs. Targeting devs with irrelevant content. A few weeks back I remember seeing a "SOC 2 for devs" blog article and was really scratching my head. That's not the level that devs work at, at all. If you're paying six figure salaries to devs to sit around all day worrying about overweight bureaucratic nonsense, or other tasks way beyond their expertise, then you're doing it wrong. I'm guessing these orgs think devs has some decision making influence or perhaps it looks good for recruiting? Or maybe they just want that HN juice. What next, I wonder? Neurosurgery for devs?
No. Kubernetes is extremely valuable to small orgs. Google Kubernetes Engine is pretty much fire & forget. You turn it on, set the maintenance window and it just works. It also saves you from having to reinvent health checks, ingresses, etc. It's actually less work than maintaining plain old servers when you factor in maintenance, and since state is immutable you don't run into issues where some developer fixed an issue 3 years ago and no one knows why it works.
Having the possibility to test stuff locally using e.g. minikube. Also in general we just build everything around docker containers. Doesn't matter if they run locally on a dev machine or in a gke cluster.
On the contrary, the DevOps team is a dev team, supported by an ops team that manages ops and exposes tools to the DevOps team to manage the lifecycle of their own deployments.
It's laughable to think every small company has infra/DevOps/platform teams.
Also, in general, it's very useful to know the platform your software is going to be deployed to, so that you can design the software with those constraints in mind.
I'm just confused why a small company would allocate ~20% (at least) of their engineering hours to maintaining something like this? The 20% number comes from updating containers, checking for security vulnerabilities, rotating secrets, monitoring health, re-deploying after an outage, documenting build processes, creating CI/CD pipelines, writing YAML, etc. etc. I just don't see why you would do that when you could pay a tiny amount of money in comparison for a managed service.
After you have the money for devops, sure, seems great, many benefits. Or if you are just doing it for fun and want to learn, also fine. Or if you have some requirement (health data or something) then great.
But that 20~ has to be the lowest leverage thing possible to spend that time and money on if you are just a regular SaaS, marketplace, <name your startup type> start up. I am genuinely interested how I would get a better return on that rather than fixing bugs, listening to customers, building features, etc.
The only thing I ever hear is "In 5 years you might be locked in and you will regret it." When, in reality, if most startups lasted 5 years, they would be ecstatic...
Same reason you would deploy to plain old servers. Your stuff has got to run somewhere. And (Google hosted) kubernetes solves a lot of issues for you out of the box, which you would otherwise have to solve eventually anyway. And it takes basically no additional maintenance, if you use a mature managed service.
You can have your developers manually copy paste files to a server, which is great while it works, but it's far better to have an automated process. At that point it's not really much more work, in fact I'd argue it's less, to pick docker + kubernetes than any of the alternatives.
Managed Kubernetes (e.g GKE) is a hosted service, just a very flexible one. There is a gap between everything runs on Heroku and Big Enough to have a DevOps team that is pretty large. You tend to outgrow heroku pretty quick if your app has much complexity at all.
Used to work somewhere that just used some VPSes instead of managed hosting. That 20% time was spent on debugging OS issues, disk space issues, OS package updates, downtime needed to increase instance sizing, documenting (read: not actually documenting just leaving it up to the next person) how to rebuild the environment etc etc.
Honest question: why do we need wholly separate devops/infra teams as opposed to just one expert to teach the other devs if K8s was supposed to make IaC so efficient?
The same reason frontend and backend teams exist. At a certain point it makes sense to have centralized teams focus on specific verticals than requiring everyone to learn/know about everything. As with any tools, there are right and wrong ways of using it and using the wrong tool for the job can sometimes be more painful than not using it at all.