4 ms·

> What’s wrong with Docker? Why would I want to switch to something else? Security, performance, reliability and following best engineering practices. Everythi

> What’s wrong with Docker? Why would I want to switch to something else? Security, performance, reliability and following best engineering practices. Everything else is fine. https://arxiv.org/pdf/1804.05039.pdf https://arxiv.org/pdf/1804.05039.pdf https://hackernoon.com/another-reason-why-your-docker-containers-may-be-slow-d37207dec27f https://hackernoon.com/another-reason-why-your-docker-contai... https://www.scylladb.com/2018/08/09/cost-containerization-scylla/ https://www.scylladb.com/2018/08/09/cost-containerization-sc... https://thehftguy.com/2017/02/23/docker-in-production-an-update/ https://thehftguy.com/2017/02/23/docker-in-production-an-upd... http://catern.com/posts/docker.html http://catern.com/posts/docker.html

tasubotadas 8y ago
It's kinda useless when it's not compared against alternatives. A crappy working solution is infinitely times better than an ideal non-working one (like Linux vs Hurd).
- eeZah7Ux 8y ago
  The alternative solution has been working for decades: software packaging.
  - gtirloni 8y ago
    Not even remotely accessible to end users like containers are today.
  - weberc2 8y ago
    Except it hasn't been working; with few exceptions we still deal with dependency hell / isolation issues in system package managers. Surely if it worked as well as you posit we would have long ago had a Kubernetes built upon apt or yum?
    - StreamBright 8y ago
      I am not sure if you have experience working with one of the leading tech companies but most of the problems you mention were solved long time ago, before containers were a thing. Apt and yum are not the right set of tools for this job, Amazon for example had an internal build and deployment system that solved dependency problems as well as environment variables, configuration management and additional aspects that even Kubernetes does not solve today.
      - weberc2 8y ago
        > I am not sure if you have experience working with one of the leading tech companies but most of the problems you mention were solved long time ago, before containers were a thing. I'm not sure what you're advocating for exactly, but the systems that the "leading tech companies" originally built were largely VM orchestration systems that required humans to pack software packages into VM images. This was suboptimal so Google et al pioneered containers and others followed suit. This is exactly what gave rise to Docker and Kubernetes. This seems a lot like saying, "ships solved the transportation problem so planes are not useful". Never mind that most people don't have the resources to build, maintain, and operate their own orchestration systems. > Amazon for example had an internal build and deployment system that solved dependency problems as well as environment variables, configuration management and additional aspects that even Kubernetes does not solve today. Build tooling is an important but orthogonal concern (you can use Bazel and friends to build container images). I'm not sure what you mean when you say Kubernetes doesn't solve those problems today. To be clear, I'm not a Docker/K8s fanatic; they can be frustrating at times and something better will surely come along and replace them eventually. However, they're a lot better than what existed before (which to be clear were not off-the-shelf solutions but rather patterns that a large, wealthy, competent organizations could use to build their own solution).
        StreamBright 8y ago
        > I'm not sure what you're advocating for exactly I am not advocating for anything just pointing out that the features atributed to Docker existed before. > but the systems that the "leading tech companies" originally built were largely VM orchestration systems that required humans to pack software packages into VM images. Absolutely not. Amazon never had such system. You are confusing Google with all leading tech companies probably. > Build tooling is an important but orthogonal concern Is this why the same features set claimed by both things? Again, what is the problem you are trying to solve with Docker/K8?
- snaky 8y ago
  Linux vs many BSD flavours. https://containerjournal.com/2019/01/22/5-container-alternatives-to-docker/ https://containerjournal.com/2019/01/22/5-container-alternat...
- StreamBright 8y ago
  Yep, you just gave me an idea of a blog post.

tasubotadas 8y ago

It's kinda useless when it's not compared against alternatives. A crappy working solution is infinitely times better than an ideal non-working one (like Linux vs Hurd).

eeZah7Ux 8y ago
The alternative solution has been working for decades: software packaging.
- gtirloni 8y ago
  Not even remotely accessible to end users like containers are today.
- weberc2 8y ago
  Except it hasn't been working; with few exceptions we still deal with dependency hell / isolation issues in system package managers. Surely if it worked as well as you posit we would have long ago had a Kubernetes built upon apt or yum?
  - StreamBright 8y ago
    I am not sure if you have experience working with one of the leading tech companies but most of the problems you mention were solved long time ago, before containers were a thing. Apt and yum are not the right set of tools for this job, Amazon for example had an internal build and deployment system that solved dependency problems as well as environment variables, configuration management and additional aspects that even Kubernetes does not solve today.
    - weberc2 8y ago
      > I am not sure if you have experience working with one of the leading tech companies but most of the problems you mention were solved long time ago, before containers were a thing. I'm not sure what you're advocating for exactly, but the systems that the "leading tech companies" originally built were largely VM orchestration systems that required humans to pack software packages into VM images. This was suboptimal so Google et al pioneered containers and others followed suit. This is exactly what gave rise to Docker and Kubernetes. This seems a lot like saying, "ships solved the transportation problem so planes are not useful". Never mind that most people don't have the resources to build, maintain, and operate their own orchestration systems. > Amazon for example had an internal build and deployment system that solved dependency problems as well as environment variables, configuration management and additional aspects that even Kubernetes does not solve today. Build tooling is an important but orthogonal concern (you can use Bazel and friends to build container images). I'm not sure what you mean when you say Kubernetes doesn't solve those problems today. To be clear, I'm not a Docker/K8s fanatic; they can be frustrating at times and something better will surely come along and replace them eventually. However, they're a lot better than what existed before (which to be clear were not off-the-shelf solutions but rather patterns that a large, wealthy, competent organizations could use to build their own solution).
      - StreamBright 8y ago
        > I'm not sure what you're advocating for exactly I am not advocating for anything just pointing out that the features atributed to Docker existed before. > but the systems that the "leading tech companies" originally built were largely VM orchestration systems that required humans to pack software packages into VM images. Absolutely not. Amazon never had such system. You are confusing Google with all leading tech companies probably. > Build tooling is an important but orthogonal concern Is this why the same features set claimed by both things? Again, what is the problem you are trying to solve with Docker/K8?
snaky 8y ago
Linux vs many BSD flavours. https://containerjournal.com/2019/01/22/5-container-alternatives-to-docker/ https://containerjournal.com/2019/01/22/5-container-alternat...
StreamBright 8y ago
Yep, you just gave me an idea of a blog post.