To say that Docker had a very rough 2017 is an understatement. Aside from Uber, I can’t think of a more utilized, hyped, and well funded Silicon Valley startup (still in operation) fumbling as bad as Docker did in 2017. People will look back on 2017 as the year Docker, a great piece of software, was completely ruined by bad business practices leading to its end in 2018. This is an outside facing retrospective on how and where Docker went wrong and how Docker’s efforts to fix it are far too little way too late.
It’s important to note that this article refers to the Docker company being dead as opposed to the software. It would be quite the overstatement to say that the software is dead given how many people use Docker for deployment, CI and development.
Personally, I’m not worried. Even if the Docker company went under there is too much momentum behind the software. If the company stopped supporting the software, there’d be a hard-fork, a new Dockerhub and things would go on.
The blog title is
Docker, Inc is Dead, which is accurate. However, I think, OP did not do same while submitting on Lobsters. I requested a title change suggestion.I’m fairly certain that the article’s title also was different a while ago.
The blog post’s title definitely was just “Docker is Dead” when this was first submitted, I checked when I was debating suggesting a different title here earlier.
Yeah. Stuff like rubygems.org lives on sponsorship from many companies, rather than a backing company. It’ll be fine. I can’t see how Docker the company matters anymore either.
There’s no mention of what will happen with all the OSS code and docker hub. I realize this isn’t an official press release, but I wish it was still mentioned. Do the current Docker owners plan on moving all their public/oss assets into a non-profit like Mozilla and keep it community driven? Do various industries plan on funding it as an open source initiative? What does this mean for Open Container and what working group will agree on the future of docker/containers?
This seems a little bit overblown to me. Whatever kind of a rough year Docker had (first I’d heard of it, and I thought I followed tech news pretty closely) it’s surely hardly on the scale of Uber’s troubles. I’d say that Node (just to name one) had a rougher time in the public eye. Juicero didn’t do so well, either.
They made some kind of a marketing blunder (Moby) but I think this was much less impactful than you think - maybe people at the conference were confused, but most people just kept right on referring to the whole thing as “Docker”, and that doesn’t seem to be a problem.
They eventually embraced Kubernetes, after realising how much momentum it had, that seems like a smart decision, and not a dumb one. Bad for the Swarm product, maybe, but by itself it hardly seems like a death-knell for the company.
There’s the link to what seems like a hearsay tweet about someone being harassed out of the company. I hope that didn’t happen, but by itself that’s not evidence of a failing company. There are (unfortunately) plenty of companies with negative internal cultures that seem to do just fine making money.
Docker has not been very good software for my team at all. We’ve managed to trigger non-stop kernel semaphore leak bugs as well as lvm filesystem bugs. Some of them going through multiple different attempts to fix. And any attempt to try to figure it out yourself by reading their code is stymied by the weird Moby/Docker disconnect that seems to be there.
If you are thinking about running docker by yourself and not in someone else’s managed docker solution then beware. It’s very sensitive to the kernel you are running and the filesystem drivers you are using it with. As far as I can tell if you aren’t running in Amazon, or Googles docker hosted solutions you are in for a bad time. And only Amazon is actually running docker. Google just sidestepped the whole issue by using their own container technology under the hood.
The whole experience has soured me on Docker as a deployment solution. It’s wonderful for the developer but it’s a nightmare for whoever has to manage the docker hosts.
A few things that bit me:
I’m sure there are more. Overall I actually do like Docker, despite some of the weirdness. However I hate how we have k8s/marathon/nomad/swarm .. there’s no one scheduler or scheduler format and if you switch from one to the other, you’re redoing a lot of tooling, labels and config to get all your services to connect together. Consul makes me want to stab myself. DC/OS uses up 2GB ~ 4GB of ram just for the fucking scheduler on each node! k8s is a nightmare to configure without a team of at least three and really ten. None of these solutions scale up from one node to a ton easily (minikube is a hack).
Containers are nice. The scheduling systems around them can go die in a fire.
[X] we’ve been bitten by this.It also has implications for monitoring so you get double the fun.
[X] we’ve established out own baseline container images and
[X] container and k8s networking was, at least until a few months ago, a mess.
[X] we hacked our own
[X] confirmed, we’re throwing money and people at it.
[X] I’ve thrown up my hands on having a working developer environment without running it on a cloud provider. We can’t trust minikube to behave sufficiently similarly as staging and production.
I’m not even sure containers are that nice, the idea of containers is nice but the execution is still half-baked.
Why do you need so many people to operate kubernetes well? And what is it enabling, to make that kind of expenditure worth it?
We’re developing a commercial turn-key, provider-independent platform based on it. Dog-fooding our own stuff has exposed many sharp bits and rough edges.
Thanks.
I’ve had a positive experience with Triton. It doesn’t support all of Docker’s features, since like Google they opted for emulating Docker and apparently decided some things weren’t having, but for the features Triton does it Just Works.
Of course, that means getting used to administering a different ecosystem.
I love the idea of Triton, but having rolled it out for a past position I worked at I can say honestly that I would not recommend it. There is no high-availability for many of the internal services by default (you need to roll your own replicas etc), there is no routing across networks (static routes and additional interfaces in every instance is not a good solution). I love Joyent as a company, and their products have a great hypothetical appeal to me as a technologist but there are just too many “buts” to justify spending the kind of money they charge for the solution they offer.
I’m just curious how old the version of Triton was, because it has had software-defined networking for ~3 years or so. Was there a limitation with it?
That stinks, but sounds more like a critique of the Linux kernel? Are you running anything custom?
Newer Docker defaults to overlayfs (no more aufs), and runs fine for us on stock Debian 9 kernels (without the extra modules package, or any dkms modules). This is both on bare metal and the AMIs Debian provides. Though we run on plain ext4, without LVM.
My experience is purely anecdotal so shouldn’t be taken as more than that.
However we aren’t on anything custom. Running latest CentOS kernels for everything and we keep it patched. The bugs aren’t in the linux kernel. It’s the way docker does things when it sets up the cgroups and manages them. My early experimentation with other container runtimes seems to indicate that they don’t have the same problems.
Just searching for the word hang in the moby project shows 171 open bugs and 521 closed. Most of them from a cursory examination look very similar to our issues. For us the tend to manifest as a deadlock in the docker engine which then causes the managed containers to go unhealthy and start a reboot loop. We’ve had to have cronjobs run and kill the docker daemons periodically in the past to keep things up and running.
Maybe there are bugs in the way Docker sets up cgroups too, but you mentioned kernel semaphore leaks and LVM bugs which seem to be squarely in the kernel? Which seems to track to me - I know when systemd started exposing all this Linux kernel-specific stuff, they were the first really big consumer so they also exposed lots of kernel bugs.