https://containerjournal.com/2019/01/22/5-container-alternat...
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).
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?
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.
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.
A crappy working solution is infinitely times better than an ideal non-working one (like Linux vs Hurd).