I too want simplicity, but Fargate still requires a load balancer in most cases. Further, you’ll probably need a database (we’ll assume something like Aurora so you needn’t think about sharding or scale so much) and S3 buckets at some point, and security obligates you to create good IAM roles and policies. You’ll need secret storage and probably third-party services to configure. Things are starting to get complex and you’re going to want to be able to know that you can recreate all of this stuff if your app goes down or if you simply want to stand up other environments and keep them in sync with prod as your infra changes, so you’re going to want some infra-as-code solution (Terraform or CloudFormation or Pulumi etc). Further, you’ll probably want to do some async work at some point, and you can’t just fork an async task from your Fargate container (because the load balancer isn’t aware of these async tasks and will happily kill the container in which the async task is running because the load balancer only cares that the connections have drained) so now you need something like async containers, lambdas, AWS stepfunctions, AWS Batch, etc.

While serverless can address a lot of this stuff (the load balancer, DNS, cert management, etc configuration could be much easier or builtin to Fargate services), some of it you can’t just wave away (IAM policies, third party servic configuration, database configuration and management, etc). You need some of this complexity and you need something to help you manage it, namely infra-as-code.

Cloud run is one of my favorite cloud services. It’s so easy to use and cheap for low traffic things. I set one up last year. GCP bills me 5 cents a month (they have no shame billing in cents)

https://issoseva.org hasn’t ever gone down.

So basically, Heroku :-)

Everyone wants Heroku but at AWS prices.

That's a problem we're trying to solve at Render. (https://render.com/) It provides much of the flexibility you get from AWS with the ease of use of Heroku, at a significantly lower cost.

Disclaimer: I work for Render

In the past I've used Cloud66, which was similar to what you described, with a Heroku-like API where you own the underlying infrastructure.

What do you use to provision managed services like rds? Or are you describing your dream UI :)

Literally that. The actual RDS ui (aws or gcp). I can setup a new db instance in 3 clicks. Slap in the dbs ip into the container.

That works when you have one container. When you have 200 and fifty databases and four identical environments (prod, qa, staging, dev) and so on it becomes a lot more error prone. These systems exist for those use cases.

Granted even with one container and a single DB I found terraform useful as I don't have to fiddle with whatever DB, container, etc. settings there are every time. I also prefer to not have to memorize or figure out a UI I use once every other month. Too many UIs across too many things.

Your point makes totally sense. Though I also like to be able to bring up (and destroy) my servers, with a single command, when needed. Going through the same ui every time is a little annoying.

Eh, they have elastic beanstalk which serves that purpose. This is for Kubernetes, which almost explicitly states is for more fine tuned control of a system that needs scalability.

I think it's both unfair and ill advised to want that type of simplicity with Kubernetes.

That being said, I don't really understand why this is necessary when there are already a lot of tools out there to manage clusters (other than AWS wanting everything to live in their console)

Yes, life is way easier if you don't have any state to worry about and you only process recoverable jobs on cattle containers and it's a team of one person taking care of it, then by all means use simple solutions.

"if you don't have any state to worry about"

You just add a db ip address to your app config? like any other solution. States work great.

This is exactly why I love Cloud Run! Combined with Firestore, it's all I need for most things I build.