6 ms·

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

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?
        weberc2 8y ago
        > I am not advocating for anything just pointing out that the features atributed to Docker existed before. No one contends that they existed before in isolation or even as a proprietary assemblage; the contention is whether or not they were available as an off-the-shelf tool or a simpler assemblage that is affordable to companies who are not "leading tech companies". > Absolutely not. Amazon never had such system. You are confusing Google with all leading tech companies probably. Why do you think "Amazon never had such a system" is a definitive rebuttal to "most leading tech companies had a system like X"? In any case, tell me about the systems that existed at leading tech companies that were comparable to Docker and accessible/practical for non-industry leaders... > Is this why the same features set claimed by both things? I'm not sure how to parse this, but it sounds like you might be implying something like "because Docker has a naive image building story, its primary purpose is to be an softare build system". > Again, what is the problem you are trying to solve with Docker/K8? Docker solves for standard software packaging and distribution; kubernetes solves for standard, efficient software orchestration. Of course you can throw really smart, well-paid engineers at the problem to devise, build, maintain, and operate a bespoke system that accomplishes a similar end.
    - ex_amazon_sde 8y ago
      I used the Amazon system a lot and saying that "Apt and yum are not the right set of tools for this job" is incorrect. APT and yum simply install packages assuming the dependencies resolve correctly. The [unnamed ;)] system could be modified to generate a set of .deb and .rpm files (with locked versions) to deploy a product.
  - deleted 8y ago
    [deleted]
  - ex_amazon_sde 8y ago
    It's still working very well for Amazon, and the company evaluated alternatives and choose to stick with packages because they have the right granularity.
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.

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?
      - weberc2 8y ago
        > I am not advocating for anything just pointing out that the features atributed to Docker existed before. No one contends that they existed before in isolation or even as a proprietary assemblage; the contention is whether or not they were available as an off-the-shelf tool or a simpler assemblage that is affordable to companies who are not "leading tech companies". > Absolutely not. Amazon never had such system. You are confusing Google with all leading tech companies probably. Why do you think "Amazon never had such a system" is a definitive rebuttal to "most leading tech companies had a system like X"? In any case, tell me about the systems that existed at leading tech companies that were comparable to Docker and accessible/practical for non-industry leaders... > Is this why the same features set claimed by both things? I'm not sure how to parse this, but it sounds like you might be implying something like "because Docker has a naive image building story, its primary purpose is to be an softare build system". > Again, what is the problem you are trying to solve with Docker/K8? Docker solves for standard software packaging and distribution; kubernetes solves for standard, efficient software orchestration. Of course you can throw really smart, well-paid engineers at the problem to devise, build, maintain, and operate a bespoke system that accomplishes a similar end.
  - ex_amazon_sde 8y ago
    I used the Amazon system a lot and saying that "Apt and yum are not the right set of tools for this job" is incorrect. APT and yum simply install packages assuming the dependencies resolve correctly. The [unnamed ;)] system could be modified to generate a set of .deb and .rpm files (with locked versions) to deploy a product.
- deleted 8y ago
  [deleted]
- ex_amazon_sde 8y ago
  It's still working very well for Amazon, and the company evaluated alternatives and choose to stick with packages because they have the right granularity.

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.