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

41–50 of 286 posts

Re: Docker's Second Death

#41

Post by indymike »

lima wrote: post #6

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

It depends on what that infrastructure is. Docker owes its existence to the OS not providing an adequate interface to create lighter containers than 00's style virtual machines. They chose to be imported and used as part of the stack by kubernetes instead of offering a better solution, which was clearly where kubernetes was headed. This one is less of a model question, than a market position question.

Elastic, on the other hand, is a very specialized application and the main issue they've had is having to compete with cloud providers (MongoDB also shares this problem). It's a very different problem, and both companies (Elastic and Mongo) seem to be finding ways to compete and cooperate. Elastic on Amazon is a great gateway drug to Elasticco's offerings.

Re: Docker's Second Death

#42

Post by AsyncAwait »

jcelerier wrote: post #23
dijit wrote: post #4

Earlier quoted context omitted.

How do you mean? The CLI? That’s `ctr`: https://github.com/projectatomic/containerd/blob/master/docs...

is it able to pull a random ubuntu or fedora image ?

Yes. The image standard for containers is called OCI and there are several ways to use them outside of Docker.

Re: Docker's Second Death

#43

Post by pm90 »

black3r wrote: post #22

Even though Kubernetes won't use Docker inside anymore.., Docker is still a very good piece of software for easily running Linux images on Windows and Mac. Dockerfile is still the easiest way to build images (even though now there are alternatives to docker build such as buildah). docker-compose is still a very simple way of running containers locally if you don't need kubernetes (e.g. on my raspberrypi for running h…

After they released local kubernetes support for the docker mac client, I've stopped using docker swarm completely. Although to be fair, I didn't use it all that frequently anyways.

If your language runtime supports testcontainers (https://www.testcontainers.org/) I would strongly suggest using that over docker compose. Docker compose is so lacking in features that I would just write bash scripts to setup/tear down container dependencies. But testcontainer removes the need to write bash scripts and provides some basic orchestration features that make it an absolute breeze to use.

Re: Docker's Second Death

#44

Post by alexellisuk »

mrskitch wrote: post #16
lima wrote: post #6

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

My own opinion: I think there is as a marketplace. Years ago when I started browserless.io, I wanted to find a way to sell access to the core image of ours. Docker kinda has/had a marketplace, where you can buy access to curated and secure images, but it didn’t get any support or news on it. Because of this we went the open-code route and just sold licenses. Too bad because I’d much rather have had a marketplace to d…

Open code or core?

OpenFaaS has been a struggle even since it was started, even with a large community and many commercial end-users, none pay for support, services or sponsor.

Most of the time saying that Open Source isn't sustainable results in some smarty dropping Elastic or some other massive VC-backed company in like GitLab. It's not helpful.

Re: Docker's Second Death

#45

Post by zapita »

I don’t understand all the drama. I remember when everyone complained that docker was too monolithic and controlled by one company. In response they spun out a spec (OCI), an implementation of that spec (runc), then their entire freaking runtime (containerd). They focused on making Docker more of a developer tool with Docker for Mac and Windows.

Kubernetes continues to use OCI, runc and containerd - so basically the parts of Docker the kubernetes community asked for.

Yet here we are commenting on their demise as a business, blaming it on their “not being nice” and “not listening to their community”. It’s bullshit. We should be discussing how the longstanding tension over the role of Docker in the Kubernetes was finally resolved, in large parts through the successful efforts of the oci, runc and containerd projects which Docker started and shepherded to mass adoption.

Let’s take a step back and look at who is pushing this narrative about Docker, and how they benefit. I can’t help but notice whenever this drama pops up, a Red Hat employee is involved. Maybe it’s time for Red Hat to give up on old grudges and give credit where credit is due? Just a thought.

Docker may have failed as a business but it’s ridiculous to blame it on their lack of openness when their number one problem was being too open and trying too hard to get everyone to love them. Basically the opposite of what this blog post claims.

Re: Docker's Second Death

#46

Post by Donckele »

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…

Phew, thanks for that. That article got me all agitated, thinking a core piece of tech I use is on its death bed with no alternatives.

Re: Docker's Second Death

#47

Post by zapita »

andrewguenther wrote: post #21
axaxs wrote: post #8

Earlier quoted context omitted.

Any good source/summary of the above? I guess I'm out of the loop, but attacking a company as trusted as Red Hat seems a bad idea.

It's difficult to dig up old drama when "Docker" is in your Google search, but this article gives a peek: https://lwn.net/Articles/676831/

Every time there’s drama about Docker being mean, it’s almost always a Red Hat employee behind it... Like this article, and the OP blog post. Maybe just a coincidence.

Re: Docker's Second Death

#48

Post by raesene9 »

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 way to use containers, without having (mostly) to worry about low-level implementation details.

Whether that can be translated to a successful business model, is another question :)

Re: Docker's Second Death

#49

Post by politelemon »

grogenaut wrote: post #26
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…

Back in 2013 before I took a job at amazon but after working with a game dev for playstation I had 2 months off, playing with docker I realized how good it's be for crap like chroot jail dev or multi-project dev env isolation. There were big blockers for it being used this way then. I did some chatting with the docker team and we did push things a little in that direction. But the vision was still about running in pr…

Their collaboration work on integration with WSL 1 and 2 has been fantastic.

Re: Docker's Second Death

#50

Post by WJW »

skrebbel wrote: post #29
goatinaboat wrote: post #19

Earlier quoted context omitted.

But Kubernetes is super complicated. It can be, but running minikube or k3s on your laptop is trivial, and what you do with them transfers very easily to real Kubernetes.

Will that allow me to ship software to servers (not enormous clusters, I mean like a couple of VMs somewhere) without having to first become a Kubernetes expert? I mean, that was one of the key Docker promises, and they delivered to quite an extent.

From my experience kubernetes is quite complicated to manage (ie for the "infra team"), but not very complicated to use as a developer. You tell it which container you want it to run and how many copies and off it goes.

If you have an existing cluster somewhere (say a managed cluster from AWS or GCP) that you want to run your webapp on, just copy/paste a YAML from any of the hundreds of guides on the internet and off you go. The k8s docs themselves are also pretty thorough. Your app will run with automatic failover and rolling deploys and whatnot right out of the box.

Post reply on HN