10 ms·

you need something to run the containers anyway, and with all the management overhead docker and other systems adds, one can just cut the chase and let an orche

you need something to run the containers anyway, and with all the management overhead docker and other systems adds, one can just cut the chase and let an orchestrator do it

valenterry 6y ago
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.
- rualca 6y ago
  > 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.
  - valenterry 6y ago
    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)
    - rualca 6y ago
      > 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.
      - jfengel 6y ago
        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.
        rualca 6y ago
        > A dozen lines of code is a lot. Are you really trying to argue that using 1 or 2 lines of YAML per component to define how an entire application is deployed and scaled is a lot? How many lines of CloudFormation would you need to do just that? And... I mean... What's your alternative to a infrastructure-as-code config file? Clicking around a dashboard to treat your app as a pet? > Especially when it's in a language you don't know and don't already have installed. It's self-describing YAML (or JSON). It's not a arcane special purpose DSL like cloidformation or SAM, or a convoluted Python program like CDK.

you need something to run the containers anyway, and with all the management overhead docker and other systems adds, one can just cut the chase and let an orchestrator do it

valenterry 6y ago

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.

rualca 6y ago
> 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.
- valenterry 6y ago
  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)
  - rualca 6y ago
    > 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.
    - jfengel 6y ago
      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.
      - rualca 6y ago
        > A dozen lines of code is a lot. Are you really trying to argue that using 1 or 2 lines of YAML per component to define how an entire application is deployed and scaled is a lot? How many lines of CloudFormation would you need to do just that? And... I mean... What's your alternative to a infrastructure-as-code config file? Clicking around a dashboard to treat your app as a pet? > Especially when it's in a language you don't know and don't already have installed. It's self-describing YAML (or JSON). It's not a arcane special purpose DSL like cloidformation or SAM, or a convoluted Python program like CDK.