> Kubernetes allows you to do just that with about a dozen lines of a infrastructure-as-code script. Apart from what was already mentioned - what if I exceed t

> Kubernetes allows you to do just that with about a dozen lines of a infrastructure-as-code script. Apart from what was already mentioned - what if I exceed the number of machines in my cluster? What if I want XGB RAM and there is no such big machine in the cluster? I don't even have to ask these questions if I use fargate because I don't care about the underlying cluster at all. > Kubernetes does that out-of-the-box, and allows you to keep your entire deployment in a repository. You've got it backwards. Kubernetes allows a configuration where you can access the containers. And now, if I have to deal with a system using Kubernetes, I don't know if someone sometimes accesses the containers unless I look at the code and check that it is up to date / successfully deployed. > With Kubernetes, health checks are 3 or 4 lines of code in a deployment definition. Yeah and code in your running service and monitoring and alerting... and and and. Maybe for you these are small differences, but for me that is a huge maintenance burden. > Oh, and unlike Fargate, you can take your Kubernetes scripts and deploy your app on any service provider that offers Kubernetes. That's certainly an advantage. But it doesn't make Kubernetes simpler. And that is what we are discussing