Maybe it's me but it feels like in a world where developers know the basics of how to build a container image, container-driven workflows stand to offer the eas

Maybe it's me but it feels like in a world where developers know the basics of how to build a container image, container-driven workflows stand to offer the ease that people originally expected from the cloud. Since I'm an ops-curious/leaning developer, it's hard for me to see how we don't standardize on this the way to deploy going forward. I'd never touch a buildpack if deploy-by-container was available but maybe this says more about me and most developers are the other way. First the "almost" container (or container-but-not-called-that + lots of other stuff) approaches popped up: - Google App Engine - AWS Elastic Beanstalk - AWS ECS Now the "actually just give us a container" solutions seem to be growing/moving: - Heroku (with containers, not buildpacks) - Google Cloud Run - Render - Fly.io - AWS Appp Runner I'd also dare to propose that a vast portion of the developers opting for Kubernetes are doing it just to have this -- being able to throw up a container and have the rest be managed for you. Kubernetes is much more interesting than that on the ops side, but you honestly don't need it if you don't want to do anything fancy ops wise -- if all you're doing is running a rails/django/(nuxt|next|nest)js app with a database like Postgres RDS, you can be up and running without the rest of it, and scale up to your first 1000+ customers before trying to do anything fancy. If you pick a decent enough database (a nice extensible one like postgres) you may not even need a real queue or full text search for a while. Feels like 90% of CRUD-y or SaaS-y apps out there never need more than app container + DB + Redis + S3 + Queues, and if it's simple enough there's no need to turn to other solutions. Expose everything to the internet (and use the appropriate security) and you don't even need to muck with networks anymore.