Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker's Second Death

tariqislam.com

Post reply on HN
Print view View original

101–110 of 286 posts

Re: Docker's Second Death

#101

Post by 0xFACEFEED »

joana035 wrote: post #60
skrebbel wrote: post #11

I feel like I'm missing some key insight here. To me, the tl;dr of this post is: Kubernetes removed the need for Docker just to run container images in a k8s cluster, ergo, Docker is dead. But Kubernetes is super complicated . The author seems to assume that everybody wants to run everything in Kubernetes, but if I want to run some backend on some server (or maybe on a few servers), then it feels like extreme overkil…

> But Kubernetes is super complicated I find quite cute that in 2020 people are still echoing this to the extent that now I have to answer questions like "explain what kubernetes is" during job interviews. To me seems that a bigger group of people get jealous about a smaller group getting new tools. Then this "stuff x is complicated" propaganda is passed on through the industry like the plague.

k8s is complicated (have you seen the docs on node affinity and taints? come on). i've seen several cases where a group of k8s experts pitched the infra as easy to configure/maintain and 12 months later they're being crushed by the weight of all k8s abstractions.

i don't blame you. k8s is great job security ;) for now.

Re: Docker's Second Death

#102

Post by ianlevesque »

musicale wrote: post #93
raesene9 wrote: post #48

To me this article conflates the removal of a piece of legacy hard-coding (dockershim) with the overall death of Docker. That removal doesn't mean that Docker won't be used as part of Kubernetes clusters any more, Docker/Mirantis have committed to creating a CRI plugin for Docker. But realistically Docker the product is primarily a developer tool and I don't see that going away. Docker for Windows/Mac is the easiest…

> Docker for Windows/Mac is the easiest way to use containers This is depressing. Even more depressing is that macOS still doesn't seem to have native containers. (Correct me if I'm wrong - perhaps the sandboxing system can be used as a container system including virtual network interfaces attached to process groups?) Docker images depend on Linux which means "Docker" on macOS runs in a Linux VM. Presumably docker fo…

It does use WSL2 if present.

Re: Docker's Second Death

#103

Post by matsemann »

joana035 wrote: post #84
TuringNYC wrote: post #65

The article and some of the comments are a strange take. There is a place for docker. There is a place for Kubernetes. They dont have much overlap in my mind. If I want to run an elastic production system with many components, and scale each component independently, i'd use Kubernetes. ...But if I want to run a Jupyter+PyTorch stack easily w/o wasting half a day on CUDA library dependency issues, I would use Docker w…

> 2. Ingress Controller hell > 2b. Ingress Controller route/path/url annotation hell... Sorry, but that is no hard at all and I can't imagine why you compare it to "hell". It is literally less than 20 lines to define an ingress object.

Sometimes I've spent hours on a single config line, so having to write 20 of some unknown thing sounds scary. And it's irrelevant for what he is trying to do, which is to run something locally. With docker that's one command, vs having to set up all the other stuff as well.

I've been very fan of using docker for all our dev stuff. To run something locally before it meant having correct version of lots of stuff, and possible having installed some database, configure it correctly etc. Onboarding could be days of configuring this stuff and having something fail. Now it's just download docker, run our ./setup.sh that spins up the various docker images, and one's almost good to go.

Re: Docker's Second Death

#104

Post by tariqislam_ »

nautilus12 wrote: post #69

I just want to make absolute sure that this is NOT the case. Does this mean that docker images built with `docker build` and pushed up to dockerhub will no longer be useable in kubernetes or not?

Container images built with `docker build` will absolutely be usable in Kubernetes. Docker produces OCI-compliant containers.

Re: Docker's Second Death

#105

Post by freedomben »

ampdepolymerase wrote: post #62
hmottestad wrote: post #12

I enjoyed the following: > Though it [Docker] does live on strongly within CI/CD ecosystems and, ostensibly, the inner loop of development thanks to the de facto standard Dockerfile. Docker will still live on for both Windows and Mac developers. As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive. Docker is still…

A bigger issue is the fact that they were not able to become a unicorn despite having a tremendously popular product. It means there is no money in development tools innovation. This is not a good thing for the software community as it means all tooling innovation will only done and controlled by the FAANGs.

I work for Red Hat but I'm a long time fan and user of Docker.

I don't think that's what this means at all honestly. Docker (the company) made some poor decisions that led to their troubles. I'm not here to crap on docker, but they quit investing in and moving their tool forward because they were focused on the EE offering. This opened the door for "competitors" to do the things docker wasn't doing (daemonless, rootless, cgroups v2, just a few). They also did things that scared people, like the whole "moby" rename thing. It made people worried that (fairly or not) Docker the company didn't have the best intentions for the open source version. They had poor direction on product. They would routinely refuse nice features that people wanted (many that included PRs) for things with terse, unkind "do not want" rejections, and then 6 months later they would end up adding it anyway. Some of these were suspected to be refused so as not to allow open source docker to compete with EE feature sets. docker-compose was the worst at this (To be fair I think it was mostly one very loud/very powerful person wrt docker-compose).

Docker started the race way ahead of everyone. To this day people still use the name "docker" to generically refer to containers.

Anyway, my point is not to crap on docker, just to say that in my opinion, in so many areas important to an open source leader, they made decisions that undermined their long term outlook.

Re: Docker's Second Death

#106

Post by pzduniak »

ianlevesque wrote: post #102
musicale wrote: post #93

Earlier quoted context omitted.

> Docker for Windows/Mac is the easiest way to use containers This is depressing. Even more depressing is that macOS still doesn't seem to have native containers. (Correct me if I'm wrong - perhaps the sandboxing system can be used as a container system including virtual network interfaces attached to process groups?) Docker images depend on Linux which means "Docker" on macOS runs in a Linux VM. Presumably docker fo…

It does use WSL2 if present.

And it works pretty well, other than some network bugs every now and then, which seem to be a WSL2 thing. I moved from OSX to Windows around the release of build 2004 and the development experience has been great.

Re: Docker's Second Death

#107

Post by freedomben »

ampdepolymerase wrote: post #100
santoshalper wrote: post #87

Earlier quoted context omitted.

I don't think that's a good read on the situation. I think a better analysis is that there is no money being what amounts to a facade on top of an operating system/kernel capability. All the real novelty and challenge to containers is in the OS itself. Everything else is more or less ease of use, which is important but relatively easy to replicate. In the span of 5 years or so, Docker went from being critical glue co…

That facade enabled millions to have easy access to that particular kernel feature. BSD jail's have been around for decades without mass adoption.

I think the GP's point is that alternatives can easily spring up when the main feature-set/value is in the kernel rather than the glue code.

Re: Docker's Second Death

#108

Post by pjmlp »

hmottestad wrote: post #12

I enjoyed the following: > Though it [Docker] does live on strongly within CI/CD ecosystems and, ostensibly, the inner loop of development thanks to the de facto standard Dockerfile. Docker will still live on for both Windows and Mac developers. As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive. Docker is still…

Not necessarily, I am yet to bother using it, and know plenty of environments where Docker still is a foreign word.

Containers should be about security not cloning local development environment.

Re: Docker's Second Death

#109

Post by pjmlp »

ampdepolymerase wrote: post #62
hmottestad wrote: post #12

I enjoyed the following: > Though it [Docker] does live on strongly within CI/CD ecosystems and, ostensibly, the inner loop of development thanks to the de facto standard Dockerfile. Docker will still live on for both Windows and Mac developers. As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive. Docker is still…

A bigger issue is the fact that they were not able to become a unicorn despite having a tremendously popular product. It means there is no money in development tools innovation. This is not a good thing for the software community as it means all tooling innovation will only done and controlled by the FAANGs.

Because the FOSS generation feels entitled to be paid while refusing to pay for tools, which leaves the typical enterprise customers as the only place one can make money with development tooling.

Re: Docker's Second Death

#110

Post by pbiggar »

cercatrova wrote: post #9
lima wrote: post #6

So, what's the better business model for a low-level piece of infrastructure like Docker?

Really, there is none. After reading through so many of these types of threads, I'm convinced there is no sustainable business model for open source infrastructure. The best bet would be to build proprietary paid services on top of the open source infrastructure. See Laravel's projects.

Fully agree. I'm going to keep your post in mind when I write about the business model of darklang.
Post reply on HN