4 ms·

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

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.
    - Legogris 7y ago
      > 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. Oh yeah, if you're not building the software in-house it's a lot less clear that "Containerizate Everything!" is the answer every time. Though there are stable helm charts for a lot of the commonly used software out there, do whatever works for you, man ;) > Containers also bring NAT and all sorts of DNS / DHCP issues that require extremely senior well rounded guys to manage. I mean, at that point you can just run with host mode networking and it's all the same, no?
      - scarface74 7y ago
        Or you can just use ECS/Fargate and each container registers itself to Route53 and you can just use DNS...
  - scarface74 7y ago
    Out of all of the business concerns that a startup or basically any company has, “cloud lock in” is at the bottom of the list.
- scarface74 7y ago
  Creating the infrastructure is using your infrastructure as code framework of choice - Terraform or CloudFormation. Monitoring can be done with whatever your cloud platform provides.
deleted 7y ago
[deleted]
scarface74 7y ago
If you need to fail and scale independently. -you can use small EC2 instances behind an application load balancer and within autoscaling groups with host based routing for request routing. - converting a stand-alone api to a container is not rocket science and nor should it require any code rewrite. - if you need to run scheduled Docker containers that can also be done with ECS or if it is simple enough lambda. - the first thing you should worry about is not “containerization”. Its getting product market fit. As far as needing containerization for orchestration, you don’t need that either. You mentioned Nomad. Nomad can orchestrate anything - containers, executables, etc. Not to mention a combination of Consul/Nomad is dead simple. Not saying I would recommend it. In most cases (I’ve used it before), but only because the community and ecosystem is smaller. But if you’re a startup, you should probably be using AWS or Azure anyway so you don’t have to worry about the infrastructure.

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.
  - Legogris 7y ago
    > 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. Oh yeah, if you're not building the software in-house it's a lot less clear that "Containerizate Everything!" is the answer every time. Though there are stable helm charts for a lot of the commonly used software out there, do whatever works for you, man ;) > Containers also bring NAT and all sorts of DNS / DHCP issues that require extremely senior well rounded guys to manage. I mean, at that point you can just run with host mode networking and it's all the same, no?
    - scarface74 7y ago
      Or you can just use ECS/Fargate and each container registers itself to Route53 and you can just use DNS...
- scarface74 7y ago
  Out of all of the business concerns that a startup or basically any company has, “cloud lock in” is at the bottom of the list.
scarface74 7y ago
Creating the infrastructure is using your infrastructure as code framework of choice - Terraform or CloudFormation. Monitoring can be done with whatever your cloud platform provides.

deleted 7y ago

[deleted]

scarface74 7y ago

If you need to fail and scale independently. -you can use small EC2 instances behind an application load balancer and within autoscaling groups with host based routing for request routing. - converting a stand-alone api to a container is not rocket science and nor should it require any code rewrite. - if you need to run scheduled Docker containers that can also be done with ECS or if it is simple enough lambda. - the first thing you should worry about is not “containerization”. Its getting product market fit. As far as needing containerization for orchestration, you don’t need that either. You mentioned Nomad. Nomad can orchestrate anything - containers, executables, etc. Not to mention a combination of Consul/Nomad is dead simple. Not saying I would recommend it. In most cases (I’ve used it before), but only because the community and ecosystem is smaller. But if you’re a startup, you should probably be using AWS or Azure anyway so you don’t have to worry about the infrastructure.