You're oversimplifying the problem and/or not viewing the problem for the organization. Maybe for an individual developer it's easier to create a Dyno or a Beanstalk deployment, but it's not necessarily easier for the organization.

IMO, Kubernetes solves a lot of issues for both camps but most of the Kubernetes detractors I've met are only hostile to it because of ignorance, not any reasonable criticisms. "It's different, it's hard or it's something I don't know" aren't valid excuses.

Easier to deploy for the developers is better for the organization. The dev team should own this process since they are the ones that probably have to support it. Objectively, deploying on any of the more managed AWS services, App Runner, ECR, Beanstalk is better for the org. Less risk if someone is leaving, vs the 3 terabytes of Kubernetes scripts required. The team knows how to manage and deploy their stuff so when they're on call they know how to fix it. Why would someone learn Kubernetes when you can spend 5 minutes learning Beanstalk or App Runner?

Things were never a problem when devs just managed this stuff. We used Heroku or Capistrano on plain EC2 and it was fine. Once you hit scale and things become more expensive then Docker on ECR / Fargate is fine. This whole dev ops fad just has to go.

Anecdotally, I was part of an organization that was all in on Beanstalk (hundreds of apps) that did a full migration to Kubernetes and we ended up reducing our spend, deploy times and pipeline complexity by half. We're talking a total yearly cloud spend probably near 9 digits. Moving to Kubernetes vastly simplified our lives and developers were able to learn it pretty easily. Development team was in the low hundreds.

So for every story I hear about "it was better back then", I just remember how much it was a horror for us and find it really hard to believe people voicing these options are actually arguing in good faith.

If that's your experience with it, then it sounds like a success and I'll concede that.

My experience is: devops is introduced to 2 orgs I was at (much smaller dev teams) to save money. Even though hiring devops negates any savings, but that's another story. They introduce Kubernetes (even though existing solutions were fine) as the flavor of the month to build up their resumes. They all leave after 6 months to a year and dev teams are stuck with the cleanup trying support and be in call for things we had no say in. It's harder to see logs, get a rails console, deploy, debug, etc.

Meanwhile they also spent 6 months trying to get PR apps and staging environments at one company. Something that is one click on Heroku.

If we didn't have Heroku at these companies when we started out we would have literally failed. End of story.

Personal rant: the solution to fixing a broken k8s installation made by a previous team in an attempt at some sort "enterprisey" lock-in is, apparently, wiping the clusters and creating a new k8s from scratch.

This isn't the future I wanted, let's solve these problems in some other way. K8s seems to be the second-system effect in all the worst ways.

Sounds like an unfortunate edge case that shouldn't detract from all the good things Kubernetes affords.

I haven't seen any good things brought by Kubernetes.

My main complaint about Kubernetes is that it feels like a https://en.wikipedia.org/wiki/Galactic_algorithm - unless you're FAANG-scale, the extra overhead and complexity it imposes to use it at all massively outweigh its benefits. And it's usually not that it's different things that you have to understand, but rather that it's more things, to accomplish the same final goal. E.g., to set up networking without Kubernetes, you need to understand traditional networking architecture, but to set up networking with Kubernetes, you need to understand traditional networking Architecture and the Kubernetes way of doing networking.