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

151–160 of 286 posts

Re: Docker's Second Death

#151

Post by yjftsjthsd-h »

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.

> It is literally less than 20 lines to define an ingress object.

...and this is your idea of easy? For something that should be as simple as "this path goes to this group" + "this group is these containers"?

Re: Docker's Second Death

#152

Post by kbenson »

pjmlp wrote: post #109
ampdepolymerase wrote: post #62

Earlier quoted context omitted.

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.

I wonder if a timed open source license would work? One in which code/features were automatically scheduled by the license to revert to GPL/BSD/whatever at a point a year or three in the future?

I think that might sap some of the impetus to reinvent those features in a competing open source project (they can of course just copy them if they wait), and also might entice people to pay that wouldn't normally because they don't want to get on the paid product train. Users also get a known date a feature will be available, a real date, not a projected delivery date.

In a lot of ways it's what many companies that develop products do already to allow people to get familiar with their product (have an open source version with less features), but this allows them a better story, makes users feel more sure about what's going on, and if they release the code immediately but it's unusable for a period by other projects, that does make it harder for those projects to cleanly reimplement unless they're sure they haven't seen in (that might be a net negative for the public with a litigation happy company).

The hard part would be tracking the time, but git has ways to make that pretty simple.

Re: Docker's Second Death

#153

Post by nrvn »

tariqislam_ wrote: post #90
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…

Author here. Thanks for your comment! I struggled with this as well. I agree that I might be conflating things a bit, but I did try to contextualize the slow but gradual move away from all things docker with the fate of the company, starting with the platform wars and resulting in the runtime deprecation. I think a lot of what happened came about because Docker took on Kubernetes with Swarm and lost.

But take a look at this from a different angle. Yes, from the business perspective Docker, inc. seems to be failing badly. But from the engineering perspective they did a tremendous job splitting the monolith to separate components. Containerd was once part of Docker daemon and then abstracted away to an independent entity. And we all hugely benefit from this split.

Now, the next big thing is happening - buildkit. It is already possible to build containers using buildkit without docker. There is even a plugin for kubectl for convenience.

Docker is tearing itself apart but I see only good things happening around it.

P.S. It has been possible to use containerd directly as CRI for Kubernetes since v1.10 https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-...

Re: Docker's Second Death

#154

Post by hiram112 »

yjftsjthsd-h wrote: post #145
enos_feedler wrote: post #114

Earlier quoted context omitted.

What kind of control are you looking for?

I'd like explicit layers (transactions, I guess?) - so instead of every command making a layer, I could write FROM alpine STARTLAYER RUN apk update RUN apk upgrade RUN apk add foo ENDLAYER and end up with a 2-layer image (alpine + my stuff) rather than the 4-layer image that docker would produce today.

Isn't this the same?

RUN apk update && apk upgrade && apk add foo

Re: Docker's Second Death

#155

Post by yjftsjthsd-h »

joana035 wrote: post #133
nikisweeting wrote: post #123

Earlier quoted context omitted.

I think you've been using it long enough that you forgot how much of a hurdle learning an extremely high-surface-area piece of tech is. The individual abstractions may be simple once you understand them in hindsight, but making an application developer that normally does not work with cluster management learn 100 new abstractions is not "easy".

Everything looks hard if you lack the fundamental knowledge. Doesn't mean that the tool itself is complicated, and spreading propaganda is plain wrong. Instead, I recommend to read the docs, watch videos and, most important, try it out.

Perhaps most things look hard until you understand them, but that doesn't make the learning curves the same. Having attempted to learn enough docker swarm and k8s to cover the same uses (standard "run a bunch of containers on a homogeneous group of servers to provide a webapp"), and sunk massively more time into k8s and still not figured out major sections of how it's supposed to work, I can assure you that k8s does in fact suck as a beginner, and dismissing valid criticism as propaganda is plain wrong.

Re: Docker's Second Death

#156

Post by matsemann »

joana035 wrote: post #119
matsemann wrote: post #103

Earlier quoted context omitted.

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 p…

Well, looks like some fundamental knowledge is missing here, that why everything looks like "hell" or is "scary". I wonder how many lines from this "./setup.sh" could have been avoided by trying a bit harder to understand how the ingress object works. I no longer see lazyness as a good trait in programing.

You are missing the point. In this hypothetical case I'm not interested in knowing how Kubernetes works or is deployed, I'm only interested in running my tools. It's not laziness, it's pragmatism so I can solve what I'm actually trying to solve.

Re: Docker's Second Death

#157

Post by hacknat »

mwcampbell wrote: post #149
hacknat wrote: post #51

Earlier quoted context omitted.

There’s no need for them to live on. There are open source alternatives that mimic Docker exactly. In fact on Fedora[1] the “docker” cli command is actually buildah and podman (you actually can’t install Docker on Fedora anymore - I genuinely haven’t noticed a difference). The commands are exactly the same right down to the command starting with the word “docker”. I don’t wish them ill, but literally everything has b…

> There’s no need for them to live on. Maybe not, but considering how much they gave, I think we should want them to live on, and do what we can to help them. Do we really want to live in a world where a startup company makes as big an impact on the way we develop and deploy software as Docker did, only to have all possible business taken from it by bigger players?

I understand this sentiment, but a lot of the original team and the certainly the original founder aren’t even there anymore. Not to mention that a lot of Docker’s business missteps have been self inflicted wounds.

There have been lots of great technologies that haven’t directly made their creators rich, but their good legacy usually/eventually catches up with them.

Re: Docker's Second Death

#158

Post by kelnos »

hiram112 wrote: post #154
yjftsjthsd-h wrote: post #145

Earlier quoted context omitted.

I'd like explicit layers (transactions, I guess?) - so instead of every command making a layer, I could write FROM alpine STARTLAYER RUN apk update RUN apk upgrade RUN apk add foo ENDLAYER and end up with a 2-layer image (alpine + my stuff) rather than the 4-layer image that docker would produce today.

Isn't this the same? RUN apk update && apk upgrade && apk add foo

It is, but the syntax is uglier. Also imagine that you might want to do more than just RUN in a single layer. Maybe COPY some file into the container and then RUN something that uses it.

Re: Docker's Second Death

#159

Post by setheron »

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…

Take a look into NixPkgs / NixOS

Re: Docker's Second Death

#160

Post by [deleted] »

nikisweeting wrote: post #132
nickjj wrote: post #115

Earlier quoted context omitted.

> 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. Not everyone needs an over the top Kubernetes cluster in production. I'm plenty happy using Docker Compose in production and foresee myself continuing to use it as long as Docker maintains it. There's even a WIP issue on their roadmap[0] to rewrite Docker Comp…

I second this, we've been running Docker Compose in production for years and love it. It's massively simplified our production environment, and for a company that only serves 100,000-1,000,000 monthly hits it's the perfect middle ground. We've tried k8s several times and have always ended up going back because we didn't need the complexity. We even run compose v2.4 to retain the ability to set container memory/cpu li…

[deleted]
Post reply on HN