5 ms·

No need to change your mind. Containers improve orchestration of deploying scalable services. The Kubernetes ecosystem will continue to improve and one day your

No need to change your mind. Containers improve orchestration of deploying scalable services. The Kubernetes ecosystem will continue to improve and one day your boss will tell you that you have to use containers to deploy your apps or find a different job.

carapace 6y ago
That's so not what I meant and I think you know it. I don't mean to be rude but your response make you sound like a systemd enthusiast. Do you have a technical argument to put forward?
- ketzu 6y ago
  I mean, "systemd enthusiast" doesn't sound rude, unless you give it some tone, are part of a special group where it is, or prefix it with "i don't mean to be rude". For the difference of Docker and reinventing OSes, it depends on what you establish as reinventing OSes. Docker provides some form of separation/containerization, a function that is also implemented by some OS. But it's discussable of having the functionality in user or kernelspace or having a wrapper application with a consistent api across multiple operating systems isn't worth it.
  - carapace 6y ago
    I had just read "Systemd, ten years later: a historical and technical retrospective" so it was on my mind. I know they didn't invent it but I associate that kind of attitude with that project. Shouldn't have mentioned it, really. https://news.ycombinator.com/item?id=23062072 https://news.ycombinator.com/item?id=23062072 https://blog.darknedgy.net/technology/2020/05/02/0/ https://blog.darknedgy.net/technology/2020/05/02/0/
- techntoke 6y ago
  Absolutely, but it is hard to decipher if it is even worth arguing at all. Would you argue against the crowd opposing automobiles? I mean, there are plenty of valid arguments against them but at the same time what good does it do to fight about it?
  - carapace 6y ago
    > it is hard to decipher if it is even worth arguing at all Then why? I mean, I put it in parentheses for a reason man. I mean, you seem to be saying that I can't tell the difference between automobiles and, what? horses? Surely if the difference is that great it should be easy to come up with lots of solid points to "change my mind"? Since you're taking the trouble to comment anyway? In your sib comment https://news.ycombinator.com/item?id=23071602 https://news.ycombinator.com/item?id=23071602 you seem to be making some solid points, but from my POV it still sounds like "learn the thing" where "the thing" does what I can already do without it, or it enables me to do stuff that I'm not actually interested in doing. Bottom line: if you want to argue please do it with facts and not dismissive condescension. (I've got plenty of that already without your help, thanks.)
ctrlc-root 6y ago
Not really. Let me prefix my reply with some context: I've used Puppet, Salt Stack, Ansible, and PowerShell DSC to manage infrastructure based on Windows, Linux, and macOS on top of bare metal servers, VMs, and containers. Any tool that promises to "make the complex simple" is really just hiding the complexity away from you behind default settings and their own implementation. Which is probably fine for simple use cases. If your application can be deployed to Heroku then deploying to a Kubernetes cluster you don't have to manage is probably analogous in terms of overhead and how much complexity you have to worry about. However this simply doesn't scale as your application increases in complexity. In fact I recently completed a migration away from Docker/Kubernetes to an AWS stack that doesn't use anything higher level than autoscaling groups and it has been a positive experience. The same application is now faster (less layers necessary), easier to deploy (we own all the moving pieces), easier to debug in production (I can use strace and tcpdump without trying to install them in an already running Docker container), etc. All of the "complexity" that Docker and Kubernetes were handling for us has been replaced with a ~ 500 line Python script that's mostly comments (you can see an early prototype of this script in the repository below, named deploy_build.py, which omits some error handling but weighs in at ~ 150 LoC). Furthermore, now that we have to think about how to package and deploy our application to production, the incentives are there to follow proper Python best practices around packaging (i.e. use packages, don't make assumptions about paths, etc) which has been a nice bonus. Containers (and Docker, Kubernetes, etc) are all tools that have their use cases and corresponding tradeoffs. Anyone who can't explain when or why you wouldn't want to use a tool is not prepared to explain when or why you should use it. https://github.com/CtrlC-Root/proto-aws-django https://github.com/CtrlC-Root/proto-aws-django
- techntoke 6y ago
  First, containers don't necessarily make complex simple. What they do is take an OS image, and allow you to run it on another OS (best performance is always going to be Linux on Linux, since containers were first built natively into the Linux kernel). Obviously, Microsoft also saw your same vision of containers being so unnecessary that they also decided to build the concept into their OS as well. This concept can't be done on bare metal. Additionally, because it is built into the kernel and they share the same kernel, they generally startup at over 10x performance of traditional VMs. There are solutions now of course to boot directly into the kernel from a hypervisor, but these are generally paired with container solutions as well due to the orchestration and ecosystem that exists to make container orchestration easy. Most container solutions use a unified image solution that allows you to rapidly reiterate and test your changes in multiple environments. Doing this on bare-metal or VMs takes considerably more time and money for fixed infrastructure costs. With container solutions such as Kind and Helm, you can rapidly deploy a local cluster to pre-test cloud rollouts on a single machine. The orchestration can also autoscale clusters horizontally and vertically, and is robust enough to directly compete with other bulkier VM orchestration solutions such as OpenStack. With automatic certificate rotation, automated service discovery, etc there is no need to try to create tasks for every little thing you'd need to do with Ansible or another IaC component. It is all baked into the Kubernetes ecosystem. Abstraction away from cloud-specific solutions can only be seen as a good thing. People that are invested in AWS generally can't be trusted to create holistic solutions.
_jal 6y ago
Eh. They're the new shiny. And they do make certain things a bit nicer for some job roles, at the cost of shoving the complexity somewhere else. In particular, it has been useful to move our engineers to developing using it. We'll probably experiment with using it in production for a few things at some point, just for consistency, but it buys us zero value there otherwise. (We will never run "in the cloud" because it would be cost-prohibitive, at least with current cloud revenue models.) There will be another new shiny in a few years, at which point the True Believers will move on and tell you how you'll lose your job if you don't get on board that train, too.

carapace 6y ago

That's so not what I meant and I think you know it. I don't mean to be rude but your response make you sound like a systemd enthusiast. Do you have a technical argument to put forward?

ketzu 6y ago
I mean, "systemd enthusiast" doesn't sound rude, unless you give it some tone, are part of a special group where it is, or prefix it with "i don't mean to be rude". For the difference of Docker and reinventing OSes, it depends on what you establish as reinventing OSes. Docker provides some form of separation/containerization, a function that is also implemented by some OS. But it's discussable of having the functionality in user or kernelspace or having a wrapper application with a consistent api across multiple operating systems isn't worth it.
- carapace 6y ago
  I had just read "Systemd, ten years later: a historical and technical retrospective" so it was on my mind. I know they didn't invent it but I associate that kind of attitude with that project. Shouldn't have mentioned it, really. https://news.ycombinator.com/item?id=23062072 https://news.ycombinator.com/item?id=23062072 https://blog.darknedgy.net/technology/2020/05/02/0/ https://blog.darknedgy.net/technology/2020/05/02/0/
techntoke 6y ago
Absolutely, but it is hard to decipher if it is even worth arguing at all. Would you argue against the crowd opposing automobiles? I mean, there are plenty of valid arguments against them but at the same time what good does it do to fight about it?
- carapace 6y ago
  > it is hard to decipher if it is even worth arguing at all Then why? I mean, I put it in parentheses for a reason man. I mean, you seem to be saying that I can't tell the difference between automobiles and, what? horses? Surely if the difference is that great it should be easy to come up with lots of solid points to "change my mind"? Since you're taking the trouble to comment anyway? In your sib comment https://news.ycombinator.com/item?id=23071602 https://news.ycombinator.com/item?id=23071602 you seem to be making some solid points, but from my POV it still sounds like "learn the thing" where "the thing" does what I can already do without it, or it enables me to do stuff that I'm not actually interested in doing. Bottom line: if you want to argue please do it with facts and not dismissive condescension. (I've got plenty of that already without your help, thanks.)

ctrlc-root 6y ago

Not really. Let me prefix my reply with some context: I've used Puppet, Salt Stack, Ansible, and PowerShell DSC to manage infrastructure based on Windows, Linux, and macOS on top of bare metal servers, VMs, and containers. Any tool that promises to "make the complex simple" is really just hiding the complexity away from you behind default settings and their own implementation. Which is probably fine for simple use cases. If your application can be deployed to Heroku then deploying to a Kubernetes cluster you don't have to manage is probably analogous in terms of overhead and how much complexity you have to worry about. However this simply doesn't scale as your application increases in complexity. In fact I recently completed a migration away from Docker/Kubernetes to an AWS stack that doesn't use anything higher level than autoscaling groups and it has been a positive experience. The same application is now faster (less layers necessary), easier to deploy (we own all the moving pieces), easier to debug in production (I can use strace and tcpdump without trying to install them in an already running Docker container), etc. All of the "complexity" that Docker and Kubernetes were handling for us has been replaced with a ~ 500 line Python script that's mostly comments (you can see an early prototype of this script in the repository below, named deploy_build.py, which omits some error handling but weighs in at ~ 150 LoC). Furthermore, now that we have to think about how to package and deploy our application to production, the incentives are there to follow proper Python best practices around packaging (i.e. use packages, don't make assumptions about paths, etc) which has been a nice bonus. Containers (and Docker, Kubernetes, etc) are all tools that have their use cases and corresponding tradeoffs. Anyone who can't explain when or why you wouldn't want to use a tool is not prepared to explain when or why you should use it. https://github.com/CtrlC-Root/proto-aws-django https://github.com/CtrlC-Root/proto-aws-django

techntoke 6y ago
First, containers don't necessarily make complex simple. What they do is take an OS image, and allow you to run it on another OS (best performance is always going to be Linux on Linux, since containers were first built natively into the Linux kernel). Obviously, Microsoft also saw your same vision of containers being so unnecessary that they also decided to build the concept into their OS as well. This concept can't be done on bare metal. Additionally, because it is built into the kernel and they share the same kernel, they generally startup at over 10x performance of traditional VMs. There are solutions now of course to boot directly into the kernel from a hypervisor, but these are generally paired with container solutions as well due to the orchestration and ecosystem that exists to make container orchestration easy. Most container solutions use a unified image solution that allows you to rapidly reiterate and test your changes in multiple environments. Doing this on bare-metal or VMs takes considerably more time and money for fixed infrastructure costs. With container solutions such as Kind and Helm, you can rapidly deploy a local cluster to pre-test cloud rollouts on a single machine. The orchestration can also autoscale clusters horizontally and vertically, and is robust enough to directly compete with other bulkier VM orchestration solutions such as OpenStack. With automatic certificate rotation, automated service discovery, etc there is no need to try to create tasks for every little thing you'd need to do with Ansible or another IaC component. It is all baked into the Kubernetes ecosystem. Abstraction away from cloud-specific solutions can only be seen as a good thing. People that are invested in AWS generally can't be trusted to create holistic solutions.

_jal 6y ago

Eh. They're the new shiny. And they do make certain things a bit nicer for some job roles, at the cost of shoving the complexity somewhere else. In particular, it has been useful to move our engineers to developing using it. We'll probably experiment with using it in production for a few things at some point, just for consistency, but it buys us zero value there otherwise. (We will never run "in the cloud" because it would be cost-prohibitive, at least with current cloud revenue models.) There will be another new shiny in a few years, at which point the True Believers will move on and tell you how you'll lose your job if you don't get on board that train, too.