> From the productivity standpoint, it is not acceptable that a Machine Learning engineer or a Full Stack Developer are expected to know Kubernetes. Or that they need to interact with a Kubernetes person/team.
I agree - these things should be abstracted from the developer - thats the goal of SRE/platform engineering - DevOps is [supposed to be] as you said, a philosophical and cultural stance around early productionization. While not mutually exclusive, they're not the same thing.
But back to your point re: orchestration-level concerns being foisted upon devs - at a shop of any size, there will be devs who feel they _need_ to touch kubernetes to get their job done (wrongly, IMHO) as well as devs who want nothing to do with it - so without engineering leadership throwing their support heavily behind a specific approach, its hard for a small team to deliver value.
> one could argue that the role of sys admins just got more specialized
Read the introduction to the SRE book, available free online [1] - and you'll see that SRE is defined _in contrast to_ systems administration. Its specifically defined as software engineering with the goal of managing operational complexity.
Modern shops' failure to understand this (most SREs haven't read any of the book, let alone stopped to think what SRE actually means) is IMHO a primary factor in the failure of most "devops transformations"
Agreed - this idea is often cited by fans of the book 'Team Topologies'. Its important here to distinguish between the idea of _an_ internal platform team and a _platform engineering_ team. A platform team is any team which provides services to internal clients - one such team would be the one (or ones) supporting whatever platforms-as-a-service are being used to deploy software to production.
You can get new tokens. Image pulling times out after ~30s, which tells me that maybe ECR is actually up, but it can't verify the caller's credentials or access image metadata from some other internal service. It's probably something low level that crashed, taking down anything built above it.
Actually, images that do not exist will return the appropriate error within a few seconds, so it's really timing out when talking to the storage layer or similar.
Newer solutions which use abstraction layers like postgREST will hopefully result in easier migration down the road - but I doubt most products/projects use such a thing.
You don't need any boilerplate to write an operator - you can write an operator in any language. I've written several in python and they all clock in under 300 sLoC
I agree - these things should be abstracted from the developer - thats the goal of SRE/platform engineering - DevOps is [supposed to be] as you said, a philosophical and cultural stance around early productionization. While not mutually exclusive, they're not the same thing.
But back to your point re: orchestration-level concerns being foisted upon devs - at a shop of any size, there will be devs who feel they _need_ to touch kubernetes to get their job done (wrongly, IMHO) as well as devs who want nothing to do with it - so without engineering leadership throwing their support heavily behind a specific approach, its hard for a small team to deliver value.