> "If this old way of doing things is so error-prone, and it's easier to use declarative solutions like Kubernetes, why does the solution seem to need sooo much work that the role of DevOps seems to dominate IT related job boards? Shouldn't Kubernetes reduce the workload and need less men power?"
Because we're living in the stone age of DevOps. Feedback cycles take ages, languages are not typed and error prone, pipelines cannot be tested locally, and the field is evolving rapidly like FE javascript did for many years. Also I have a suspicion that the mindset of the average DevOps person has some resistance to actually using code, instead of yaml monstrosities.
There is light at the tunnel though:
- Pulumi (Terraform but with Code)
- dagger.io (modern CI/CD pipelines)
Or maybe the future is something like ReplIt, where you don't have to care about any of that stuff (AWS Lambdas suck btw).
I agree with this 100%. We're in the infancy of DevOps.
Ironically, "DevOps" started as a philosophy that developers should be able to do operations, e.g. deploy, monitor their apps without relying on external people (previously called Sys Admins, etc). Yet, we're at a stage where the "DevOps" role has become the most prevalent one. IMO things have temporarily gotten slightly worse to get much better later.
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. It is an obstacle for them to produce value.
Kubernetes is not THE solution. It's just an intermediate step. IMO, in the long run there'll be very few people actually working with technologies like Kubernetes. They'll be building other, simpler tooling on top of it, to be used by developers.
You already named few examples. I can name few more:
- Railway.app
- Vercel
- Render
- fly.io
- probably many more under way
> 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.
Because we're living in the stone age of DevOps. Feedback cycles take ages, languages are not typed and error prone, pipelines cannot be tested locally, and the field is evolving rapidly like FE javascript did for many years. Also I have a suspicion that the mindset of the average DevOps person has some resistance to actually using code, instead of yaml monstrosities.
There is light at the tunnel though:
- Pulumi (Terraform but with Code)
- dagger.io (modern CI/CD pipelines)
Or maybe the future is something like ReplIt, where you don't have to care about any of that stuff (AWS Lambdas suck btw).