Or one can use a service that does the orchestration in a certain way so that one does not have to care about it, as long as one can live with the constraints of the service. E.g. AWS Fargate or GC Run.
I really can't understand this line of reasoning. How exactly is something like Fargate simpler than Kubernetes?
I understand the argument in favour of using Docker Swarm over deploying your own Kubernetes on premises or on heterogeneous cloud, but Fargate?
And using GC Run to run containerized apps completely missed the point of containerization. Containers are way more than a simple way to distribute and run isolated apps.
Well, Fargate is simpler in the way that I define CPU+RAM, give it an image, tell it how many of them to run in parallel and let it run. If something crashes it will be restarted. If I want to deploy I push a new image.
That's pretty much it. The container cannot be accessed from the outside except for the defined interfaces like http, the containers cannot discover each other unless I use something else to coordinate between them. That is all restrictive, but it also makes things simple.
I still need to do health-check and such - so if I don't really need long running containers, I can make it even simpler by using lambda. (well in theory, I don't like lambda, but that's because of the implementation only)
> Well, Fargate is simpler in the way that I define CPU+RAM, give it an image, tell it how many of them to run in parallel and let it run.
Kubernetes allows you to do just that with about a dozen lines of a infrastructure-as-code script.
> That's pretty much it. The container cannot be accessed from the outside except for the defined interfaces like http, the containers cannot discover each other unless I use something else to coordinate between them. That is all restrictive, but it also makes things simple.
Kubernetes does that out-of-the-box, and allows you to keep your entire deployment in a repository.
> I still need to do health-check and such - so if I don't really need long running containers, I can make it even simpler by using lambda.
With Kubernetes, health checks are 3 or 4 lines of code in a deployment definition.
And it's used to manage auto-scaling.
Oh, and unlike Fargate, you can take your Kubernetes scripts and deploy your app on any service provider that offers Kubernetes.
A dozen lines of code is a lot. Especially when it's in a language you don't know and don't already have installed. Often, the most difficult program to write is "hello, world", since when it fails, it fails in ways that are difficult to understand and specific to your installation and infrastructure. It can be hard to get help for those.
I'm sure that once you've bitten the bullet and learned Kubernetes, these things are easy. But for a lot of use cases it's great to avoid having to bite that bullet, do a one-click thing, and get back to your core development.
> 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
