4 ms·

It's an afternoon worth of research to understand the basic concepts. Then, with the powerful and intuitive tooling you can spin up your own cluster on your com

by nrb 7y ago

It's an afternoon worth of research to understand the basic concepts. Then, with the powerful and intuitive tooling you can spin up your own cluster on your computer in minutes and practice deploying containers that: - are automatically assigned to an appropriate machine(node) based on explicit resource limits you define, enabling reliable performance - horizontally scale (even automatically if you want!) - can be deployed with a rolling update strategy to preserve uptime during deployments - can rollback with swiftness and ease - have liveness checks that restart unhealthy apps(pods) automatically and prevent bad deploys from being widely released - abstracts away your infrastructure, allowing these exact same configs to power a cluster on-prem, in the cloud on bare metal or vms, with a hosted k8s service, or some combination of all of them All of that functionality is unlocked with just a few lines of config or kubectl command, and there are tools that abstract this stuff to simplify it even more or automate more of it. You definitely want some experienced people around to avoid some of the footguns and shortcuts but over the last several years I think k8s has easily proven itself as a substantial net-positive for many shops.

scarface74 7y ago
So why should I do all of that instead of throwing a little money at AWS, run ECS and actually spend my time creating my product? Heck, if my needs are simple enough why should I even use ECS instead of just putting my web app on some VM's in an auto-scaling group behind a load balancer and used managed services?
- geggam 7y ago
  Hate to tell you this but that second idea is much easier to manage from an operations standpoint and significantly more reliable. Also easier to debug and monitor... but you run your business to make developers happy right ?
  - takeda 7y ago
    I think that was his point (you are referring to using VMs, right?)
  - p_l 7y ago
    Having worked with ECS 2.0 when Fargate was released, the setup was much harder to use from operations standpoint the moment you needed anything more complex (not to mention any kind of state) than k8s. Just getting monitoring out of AWS was annoyance involving writing lambda functions to ship logs...
    - scarface74 7y ago
      Fargate has built in logging and monitoring via CloudWatch. It redirects console output to CloudWatch logs.
      - p_l 7y ago
        And I'll be blunt that CloudWatch, especially logs, aren't all that hot in actual use. It might have gotten better, but all places I worked for last two years if they used AWS they depended on their own log aggregation, even if using AWS-provided Elastic Search.
        scarface74 7y ago
        There are other supported options. https://aws.amazon.com/blogs/opensource/fargate-container-logs-collection-analysis-firelens-sumo-logic/ https://aws.amazon.com/blogs/opensource/fargate-container-lo...
      - rclayton 7y ago
        CloudWatch sucks. Sorry.
- Legogris 7y ago
  I don't think anyone is arguing that you should use k8s for a simple web app. There's definitely some inherent stack complexity threshold before solutions like k8s/mesos/nomad are warranted. When you start having several services that need to fail and scale independently, some amount of job scheduling, request routing... You're going to appreciate the frameworks put in place. My best advice is to containerize everything from the start, and then you can start barebones and start looking at orchestration systems when you actually have a need for it.
  - geggam 7y ago
    What requirement is driving containers ? How are you managing your infrastructure and if you have that already automated how much effort is it to add the software you develop to that automation vs the ROI of adding another layer of complexity ? The idea everything needs to be in containers is similar to the idea everything needs to be in k8s. Let the business needs drive the technology choices don't drive the business with the technology choices
    - Legogris 7y ago
      Portability - the idea being that you can migrate to an orchestration technology that makes sense when you have the need. The cost and effort of containerizing any single service from the get-go should be minimal. It also helps a lot with reproducibility, local testing, tests in CI, etc. Valid reasons to not run containerized in production can be specific security restrictions or performance requirements. I could line up several things that are not suitable for containers, but if you're in a position of "simple but growing web app that doesn't really warrant kubernetes right now" (the comment I was replying to), I think it's good rule of thumb. I agree with your main argument, of course.
      - geggam 7y ago
        The overhead managing a container ecosystem to run production is not trivial. IF you are doing this in a service then by all means leverage that package methodology. If you are managing your systems who already have a robust package management layer then adding the container stacks on top of managing the OS layers you have just doubled the systems your operations team is managing. Containers also bring NAT and all sorts of DNS / DHCP issues that require extremely senior well rounded guys to manage. Developers dont see this complexity and think containers are great. Effectively containers moves the complexity of managing source code into infrastructure where you have to manage that complexity. The tools to manage source code are mature. The tools to manage complex infrastructure are not mature and the people with the skills required to do so ... are rare.
- deleted 7y ago
  [deleted]
hedora 7y ago
> It's an afternoon worth of research to understand the basic concepts. Then, with the powerful and intuitive tooling you can spin up your own cluster on your computer in minutes and practice deploying containers that. Source? I’ve never heard of someone going from “what’s kubernetes?” to a bare metal deployment in 4 hours.
- p_l 7y ago
  That's more for minikube, which is a few minutes to run, as it is specifically for developer to test things locally on their computer. The basic concepts in k8s are also pretty easy to learn, provided you go from the foundations up -- I have a bad feeling a lot of people go the opposite way.

by nrb 7y ago

scarface74 7y ago

So why should I do all of that instead of throwing a little money at AWS, run ECS and actually spend my time creating my product? Heck, if my needs are simple enough why should I even use ECS instead of just putting my web app on some VM's in an auto-scaling group behind a load balancer and used managed services?

geggam 7y ago
Hate to tell you this but that second idea is much easier to manage from an operations standpoint and significantly more reliable. Also easier to debug and monitor... but you run your business to make developers happy right ?
- takeda 7y ago
  I think that was his point (you are referring to using VMs, right?)
- p_l 7y ago
  Having worked with ECS 2.0 when Fargate was released, the setup was much harder to use from operations standpoint the moment you needed anything more complex (not to mention any kind of state) than k8s. Just getting monitoring out of AWS was annoyance involving writing lambda functions to ship logs...
  - scarface74 7y ago
    Fargate has built in logging and monitoring via CloudWatch. It redirects console output to CloudWatch logs.
    - p_l 7y ago
      And I'll be blunt that CloudWatch, especially logs, aren't all that hot in actual use. It might have gotten better, but all places I worked for last two years if they used AWS they depended on their own log aggregation, even if using AWS-provided Elastic Search.
      - scarface74 7y ago
        There are other supported options. https://aws.amazon.com/blogs/opensource/fargate-container-logs-collection-analysis-firelens-sumo-logic/ https://aws.amazon.com/blogs/opensource/fargate-container-lo...
    - rclayton 7y ago
      CloudWatch sucks. Sorry.
Legogris 7y ago
I don't think anyone is arguing that you should use k8s for a simple web app. There's definitely some inherent stack complexity threshold before solutions like k8s/mesos/nomad are warranted. When you start having several services that need to fail and scale independently, some amount of job scheduling, request routing... You're going to appreciate the frameworks put in place. My best advice is to containerize everything from the start, and then you can start barebones and start looking at orchestration systems when you actually have a need for it.
- geggam 7y ago
  What requirement is driving containers ? How are you managing your infrastructure and if you have that already automated how much effort is it to add the software you develop to that automation vs the ROI of adding another layer of complexity ? The idea everything needs to be in containers is similar to the idea everything needs to be in k8s. Let the business needs drive the technology choices don't drive the business with the technology choices
  - Legogris 7y ago
    Portability - the idea being that you can migrate to an orchestration technology that makes sense when you have the need. The cost and effort of containerizing any single service from the get-go should be minimal. It also helps a lot with reproducibility, local testing, tests in CI, etc. Valid reasons to not run containerized in production can be specific security restrictions or performance requirements. I could line up several things that are not suitable for containers, but if you're in a position of "simple but growing web app that doesn't really warrant kubernetes right now" (the comment I was replying to), I think it's good rule of thumb. I agree with your main argument, of course.
    - geggam 7y ago
      The overhead managing a container ecosystem to run production is not trivial. IF you are doing this in a service then by all means leverage that package methodology. If you are managing your systems who already have a robust package management layer then adding the container stacks on top of managing the OS layers you have just doubled the systems your operations team is managing. Containers also bring NAT and all sorts of DNS / DHCP issues that require extremely senior well rounded guys to manage. Developers dont see this complexity and think containers are great. Effectively containers moves the complexity of managing source code into infrastructure where you have to manage that complexity. The tools to manage source code are mature. The tools to manage complex infrastructure are not mature and the people with the skills required to do so ... are rare.
deleted 7y ago
[deleted]

hedora 7y ago

> It's an afternoon worth of research to understand the basic concepts. Then, with the powerful and intuitive tooling you can spin up your own cluster on your computer in minutes and practice deploying containers that. Source? I’ve never heard of someone going from “what’s kubernetes?” to a bare metal deployment in 4 hours.

p_l 7y ago
That's more for minikube, which is a few minutes to run, as it is specifically for developer to test things locally on their computer. The basic concepts in k8s are also pretty easy to learn, provided you go from the foundations up -- I have a bad feeling a lot of people go the opposite way.