18 ms·

Goodbye Docker and Thanks for all the Fish

378 points by Corrado 8y ago

yuriko 8y ago
Dupe of https://news.ycombinator.com/item?id=19350571 https://news.ycombinator.com/item?id=19350571
- tomhoward 8y ago
  It's not a dupe if the earlier submission(s) got few/no comments/upvotes.
gfiorav 8y ago
So many times have we thought that a technology will prevail or disappear based on its validaty or adequatecy, and so many times have we seen the most popular survive. JavaScript comes to mind. If it’s widespread and easy to learn, it might not matter how much technically better other alternatives might be. We’ll see
- tcd 8y ago
  "BuT jQuEry iS DeaD!?!"
raesene9 8y ago
It's fair to say that in the hype cycle Docker (the technology) has passed its peak, but I don't think the conclusion that as a technology, it's finished, is warranted. Containerization is still on the rise and Docker is part of that. The toolset is still a good, fairly easy to use, place for individual developers to use containers on the client-side whilst creating containerized applications. For smaller deployments (without orchestration) a single Docker engine with things like compose, can still work well. Obviously on the orchestration side, Kubernetes has won, although it too will face the inevitable trough of disillusionment when people realise that all technologies have downsides. Personally, for simpler workloads, I think Docker swarm can still be a good answer, as it's a lot less complex than Kubernetes to set-up and maintain. The idea that the Redhat container stack (podman, CRI-O, et al) necessarily mean the end of Docker, doesn't really follow at all to me. If anything the increased use of containerd directly is a bigger threat to Docker's market share.
- wodenokoto 8y ago
  I think the main point to consider is, if Kubernetes is the technology for large deployments, who is left to buy enterprise solutions from Docker the company? And without enterprise sales, what is going to fund docker development for the small and simple docker workloads?
  - raesene9 8y ago
    Well Docker the company is a different game. They have gone quite heavily for the enterprise market and support Kubernetes as part of their Docker EE product. Of course, whether that will give them enough success to justify their valuation, is another matter. Personally, I had thought they would get bought out by one of the large tech. players who is heavily investing in containerization (e.g. Microsoft) but that doesn't seem to have happened so far.
    - pbalau 8y ago
      Amazon might have a say in this, both their ECS and EKS solutions are based on docker.
  - pknopf 8y ago
    The Docker company may not survive, but Docker will. Especially considering the work the Docker company is doing to support OCI. The dockerd internally uses containerd now, which supports both Docker images and OCI images.
    - alexandre_m 8y ago
      I always tend to think that the reason Docker developers decided to split the Docker products codebase (CE/EE) into the Moby components 2 years ago was that they foresaw the inevitable death of Docker in the long-term.
- user5994461 8y ago
  >>> It's fair to say that in the hype cycle Docker (the technology) has passed its peak, but I don't think the conclusion that as a technology, it's finished, is warranted. That's confusing the product and the technology. The technology is containerization, not Docker. Containerization is on the rise and will continue. Docker as a product AND a company, is doomed. They have no business model and no sales. All of Google/Amazon/RedHat/Linux are working on a substitute so they don't have to depend on it. The hype is in Kubernetes now and managed cloud solutions. Docker is an accidental dependency of Kubernetes, until it's finally get rid off.
mickeyp 8y ago
A shame, really, but not a huge surprise that products like Swarm fell by the wayside. I feel it could've occupied a nice middleground for teams that didn't need the full capabilities (or overhead of supporting) Kubernetes, even though I think K8s is an exceptional project. I chose Swarm as a pragmatic choice in an enterprise environment that didn't have any prior experience with Docker at all, really, at the operational level. We had to support financial models, often many different versions of the code at the same time, on top of the usual stack of applications to go with that. The choice was a "success", albeit one muted by the wacky networking layer they use. Compound that with RHEL's older kernels, and we had to deal with oddball issues like iptables/arp table getting out of sync with what's actually running, resulting in connectivity issues. And don't get me started on removing and redeploying a stack; that would occasionally wedge things so badly we had to cycle the docker daemon. Still, a shame. The gap between "Look, I wrote a compose file" and running something on a small cluster is tiny, and that was its main strength, even if it did suffer from some serious heisenbugs. Why they decided to add and remove features between versions and do their damndest not to make a compose file 100% "forwards compatible" with Swarm is another mystery.
- usgroup 8y ago
  Swarm was a pretty big mistake. I think based on just relative resource investment compared to Kube, it ought to have been obvious that it’d never be relevant if it wasn’t extremely specialised.
  - mickeyp 8y ago
    That's true. However, consider this environment: - The ops team are in a different country, and are wedded to very old-fashioned views of administration ("Automation? But I like manually running commands from a runbook!") - You work with a team of people who are quants/actuaries/scientists/engineers but not professional developers, but you want them to have a turn-key environment so they can Get On With It. When they need new python packages or god forbid upgrade pandas or something else, there's a full CI chain that'll make sure that what they do here also works there. - Swarm is (from personal experience) easy enough to teach people who don't know anything about Docker. You can show them how to query the state, modify it, look at logs, etc. all without the hassle and overhead of configuring and running K8s, even though it will always be my #1 choice for tech-literate orgs. Swarm, for many, including myself, was a pragmatic choice -- 80% of the immediate benefit of container orchestration with 20% of the cognitive overhead for the chaps in another country who had to maintain it if things went south.
vbezhenar 8y ago
For me Docker's value is to be able to easily run some Linux services with Windows. They got a lot of ready to use recipes on their website, so it's really easy to run e.g. wordpress with mysql. I would spend at least hour to manually setup VM with Ubuntu, install that stuff there. Also I'm using it to run postgresql for development. While technically I can do it just from Windows, I feel safer concentrating all that stuff inside disposable VM, also it's easy to share onboarding scripts with colleagues. I don't see how RHEL's tools would help me with that. Actually I could replace all my Docker usage with few shell scripts, but they have to be written and with Docker they are already written, many by experienced software maintainers. Docker will die when popular software will discontinue their docker images.
- ndnxhs 8y ago
  For me docker is a really convenient way to self host multiple services on one host. In the past I did it without docker and almost every service requires you to add a repo and after you do this a few times you almost always end up breaking your system and having to start again. Docker keeps things clean and easy to manage.
- fxfan 8y ago
  How's docker on Windows working out for you so far?
  - vbezhenar 8y ago
    No problems at all. There was weird problem when I tried to output binary file to stdout inside docker and redirect it inside cmd which resulted in garbage. But it wasn’t appropriate usage I guess.
tnolet 8y ago
This is a similar discussion to vinyl vs cassette vs cd vs streaming. All will keep existing in some form or another. Admittedly, some will die out completely (DCC, Minidisc) I’m pretty skeptical this going to be Docker though. Even more, the argument that because Redhat RHEL 8 no longer has a Yum repo for it Docker is dead in the water is a bit far fetched. According to Wiki RHEl is a fairly small % of the server market compared to Ubuntu, Debian and Windows for that matter. https://en.m.wikipedia.org/wiki/Usage_share_of_operating_systems https://en.m.wikipedia.org/wiki/Usage_share_of_operating_sys...
- jgillich 8y ago
  RHEL also means Fedora and CentOS, the latter is extremely popular for large scale deployments. The article is for web servers only, I think the real market share of RHEL and CentOS is more like 30-40%. Podman just makes more sense because it doesn't require a big fat daemon. You launch containers like any other service: with systemd. And you can run podman without root permissions as well, which is a huge win for security.
  - tnolet 8y ago
    Well, having worked quite a bit with RHEL and Centos in the past, I found their day to day usage quite different. Maybe that has changed. More important, I only saw RHEL at traditional Fortune 500 companies. Not sure how their market in FANG type companies is. Probably negligible. F500 is still big of course.
    - user5994461 8y ago
      FANG are making their own OS at this point so they're not really relevant. There are two distributions left in Linux, RedHat derivatives and Debian derivatives. In terms of install base, it's maybe 1/3 and 2/3. In terms of money, expect the other way around, because it's F500 who pay the most for software and they are on RedHat. RedHat is actively trying to kill docker (along Google and Amazon). RedHat removing "docker" CLI and replacing it with its own tools is a major step toward that. Docker will be de facto dead in enterprise as soon as it stops being supported by RedHat.
deleted 8y ago
[deleted]
leowoo91 8y ago
It's just normalized as any other technology, it doesn't mean company is not ready for it but that's up to how much they've been partying since.
maaaats 8y ago
This article contains really no good reasons and spends many words to say that unnamed alternatives exists. One argument is that there are no new big features. But that is completely normal when things become stable.
- cwingrav 8y ago
  Agreed. I came for rational but saw none. There seems to be a lot of hate for Docker I don’t understand. Is it community management? Is it some esoteric tech concern? Can someone more knowledgeable pipe in?
  - pknopf 8y ago
    I agree. Why do people hate Docker, the CLI. Anyone? I mean, it's slowly going OCI, so no vendor lock-in.
    - pxtail 8y ago
      HN crowd likes to gaze at FANG-like corps and treat it like gods, FANGs use Kubernetes? well then for sure docker is passe :) It doesn't matter that for some use cases swift and straightforward solutions like docker and it's ecosystem are better.
std_throwawayay 8y ago
Providing base technology doesn't seem to lead to financial success. You have to provide more concrete solutions for companies and people instead of the abstract infrastructure. I wonder if protection of the base technology through software patents could have averted this looming financial disaster.
- mixmastamyk 8y ago
  Prior art existed for a decade.
danieldk 8y ago
This post links to podman. But the podman website is completely useless, because it does not tell me what it does differently/better than docker, only that What is Podman? Simply put: `alias docker=podman` So, for someone who occasionally uses Docker for running services or creating specific build environments (manylinux1): what are the benefit of podman over Docker?
- rmk2 8y ago
  Podman doesn't have a daemon like Docker does. It also more tightly integrates with buildah, which the article doesn't expand on. Have a look at this (very brief) overview to get a bit better idea of their relationship: https://github.com/containers/buildah#buildah-and-podman-relationship https://github.com/containers/buildah#buildah-and-podman-rel... Podman also uses the same notion of pods, and it doesn't support docker-compose syntax/files, because RedHat strongly believes that Kubernetes has already won. Basically, podman/podlib allow you an easy migration path from your local computer to a k8s cluster, with the same images and same concepts. Have a look here: https://github.com/containers/buildah#buildah-and-podman-relationship https://github.com/containers/buildah#buildah-and-podman-rel...
  - nirv 8y ago
    > Podman also uses the same notion of pods, and it doesn't support docker-compose syntax/files, because RedHat strongly believes that Kubernetes has already won. Could you expand on that please? Almost everything I run locally (be it a self-hosted service or app devel) with docker is a docker-compose stack. It allows me to easily manage/monitor services via CLI or Portainer. How does Podman and other modern tools offer to solve this case, or is it proposed now to use K8s locally? I got enthusiastic about Podman not having a daemon and running Podman containers as a non-root user[1]. [1] https://opensource.com/article/18/10/podman-more-secure-way-run-containers https://opensource.com/article/18/10/podman-more-secure-way-...
  - detaro 8y ago
    The second link is the same as the first, did you mean to put a different one?
oftenwrong 8y ago
s/Goodbye/So Long/
raverbashing 8y ago
As much as docker works, I can't help feeling it is a big kludge. CLI usability is close to zero. One (temp) image per line in the Dockerfile might have some practical uses, but most of the time it doesn't. Yes it seems their days are numbered.
- pknopf 8y ago
  > CLI usability is close to zero What? > One (temp) image per line in the Dockerfile might have some practical uses, but most of the time it doesn't. I completely disagree. Cached builds being one reason, viewing the intermediate layers is just a huge benefit. Why don't you like it. You could always build with "--no-cache", which all CI should be using anyway.
  - raverbashing 8y ago
    > What? Yes. It's all over the place. https://docs.docker.com/engine/reference/commandline/cli/ https://docs.docker.com/engine/reference/commandline/cli/ It has no obvious separation of commands dealing with images/containers/running containers. Sometimes you refer to them by tags, sometimes by IDs. It's non discoverable. It's non intuitive. I can't know what 'docker rm' does without reading the docs. Oh and there is 'docker rmi' is that for images? Docker build has this nice example here: '--tag , -t Name and optionally a tag in the ‘name:tag’ format' Ok so you set a name with --tag? Compare with 'kubectl get pods' > Cached builds being one reason, viewing the intermediate layers is just a huge benefit. Sure, as I said, it is useful, but you do not want to do this most of the time. > You could always build with "--no-cache", which all CI should be using anyway. Bad defaults are an UX problem, thanks for furthering my point.
    - declnz 8y ago
      >It's non discoverable. It's non intuitive. > I can't know what 'docker rm' does without reading the docs. Oh and there is 'docker rmi' is that for images? I think you're using the old CLI. A couple of years ago, they added new syntax and "encouraged" its use by default [1] (though IME people still use the original). This is definitely more discoverable and logical; the syntax would be `docker image rm` [2] or `docker container rm` [3], etc [1] https://blog.docker.com/2017/01/whats-new-in-docker-1-13/ https://blog.docker.com/2017/01/whats-new-in-docker-1-13/ [2] https://docs.docker.com/engine/reference/commandline/image_rm/ https://docs.docker.com/engine/reference/commandline/image_r... [3] https://docs.docker.com/engine/reference/commandline/container_rm/ https://docs.docker.com/engine/reference/commandline/contain...
WestCoastJustin 8y ago
The death of the Docker as a technology is laughable. Every Cloud provider is racing to add container orchestration features and they all use Docker under the hood [1, 2, 3, 4]. Cloud providers are dumping hundreds of millions into this ecosystem through, training, credits, new features, etc. I have not seen anyone step off the gas. They are all seeing massive growth in container adoption. My guess is this is only the start. Go look at any DevOps/SRE job posting and you will see Docker, Containers, Kubernetes. This post is wrong when is comes to the technology going away anytime soon. Container orchestration is light years better than anything that we were doing on the operations side before. This is why I find it extremely hard to believe we are going back. We would need something much better to jump to and that has not been invented yet. So, Orchestration/Docker/Containers are here to stay for the foreseeable future. The rkt image format tried early on to subvert the Docker Image format and was unsuccessful. Today, there is much more depending on the existing image standard. You would totally fragment the existing integrations if you attempted to change. I am not saying that people will not try. But, I just cannot see it happening anytime soon. You have all these Clouds betting on it, you have millions of Dockerfiles out there now, and tons of people trained on it. All these CI/CD platforms supporting it. You would need some massive reason to change. Why would they? You might see people under the hood take the Docker Image and wrap it somehow, like gvisor [5], but they will still likely accept the Docker Image. Go look at these charts from Datadog about their customers Docker adoption [6]. Every single chart is hockey stick growth. This is a sampling of 10,000 companies running 700 million containers in real-world use. I am just offering a counter to the point that the image format is coming to its death. I do not see that. Disclosure: Former Docker employee. [1] https://aws.amazon.com/ecs/ https://aws.amazon.com/ecs/ [2] https://aws.amazon.com/eks/ https://aws.amazon.com/eks/ [3] https://cloud.google.com/kubernetes-engine/ https://cloud.google.com/kubernetes-engine/ [4] https://docs.microsoft.com/en-us/azure/aks/ https://docs.microsoft.com/en-us/azure/aks/ [5] https://github.com/google/gvisor https://github.com/google/gvisor [6] https://www.datadoghq.com/docker-adoption/ https://www.datadoghq.com/docker-adoption/
- nebulous1 8y ago
  He isn't saying containers are dying, he's quite clear on that.
gulikoza 8y ago
I never understood why "modern" tools like Docker have to provide everything: networking, firewall, repository, you name it... I understand somebody wanting to type "docker run xxx" and have everything setup automatically, but if you're running anything but default networking and actually care where the xxx image comes from, it's gonna fail miserably. Coming from the VM world, I found it much easier to work with macvlan interfaces that lxd supports for example - the container gets it's own interface and IP address and all networking can be prepared and set up on the host instead of some daemon thinking it knows my firewall better than me...
- empath75 8y ago
  Because most people don’t know anything about networking or firewalls and don’t want to.
  - fatherlinnux 8y ago
    Most people nothing about technology and don't want to. Not sure where that argument goes, but I am guessing jobless...
- snidane 8y ago
  Yeah, it feels too monolithic. Just to showcase it can run Hello World in one "docker run" command I guess? Another thing people use Docker for but shouldn't is application packaging. Using Docker you build one fossilized fat package with both all OS and app dependencies baked in. Then some day after years of using that Docker image you need to upgrade your OS version in the image but you can't replicate the app build because you didn't pin exact library versions and the global app repository's (pip, npm) later version of the package is no longer compatible with your app. Application packaging is better to be done in proper packaging systems like rpm od deb or other proprietary ones and stored in organization's package repository. Then you can install these rpm packages in your Docker images and deploy them into cloud. The difference in OS dependencies and app dependencies are clear when looking at contents of actual dockerfiles. OS dependencies are installed leveraging rpm or deb ecosystem. Apps are cobbled together using a bunch of bash glue and remote commands to fetch dependencies. Why not use proper packaging for both OS and apps and then just assemble the Docker image using that?
polskibus 8y ago
Honest question from someone who only used docker on several occasions to deploy 3rd party software but wants to invest into containerization. Is it worth going deep into docker right now? Is he knowledge transferrable to kubernetes and whatever else is going to replace it? I want easy deployment that properly deploys containers and telheir dependencies, but many of my scenarios don't need redundancy, scalability etc. My use cases are in-house so managed solutions won't be considered. On the other hand I don't want to have much worse operational complexity than with docker (and that's what I heard running local kubernetes biggest drawback is). Also many open source solutions provide dockerfiles, not caring about other containerization solutions. Please help, I'd rather avoid investing in an already obsolete solution if possible.
- aboutruby 8y ago
  docker-compose is quite Docker specific but the underlying concepts and the commands used in a Dockerfile can be used on any kind of setup
- raesene9 8y ago
  Docker the technology isn't obsolete now and I very much doubt it will be in the future. As you've noticed there's a load of solutions who make use of Dockerfile formats and store images on Docker hub. I'd expect that there will be future developments, but that they'll be backwardly compatible with existing deployments. Docker Engine (the daemon running on a single host) and Kubernetes (the orchestration system) largely serve different needs. Kubernetes is good for large scale deployments where it's additional complexity is warranted. For running groups of containers on a single host (or small number of hosts) Docker does just fine.
sbhn 8y ago
If you are a coder, and you want to implement auto devops yourself, for free, then see this video. https://youtu.be/Qlj6NiOy5jM https://youtu.be/Qlj6NiOy5jM You can do it to, remember the proffesionals will shout at you for using this method, it makes them obsolete.
kccqzy 8y ago
Well I can see kubernetes being the dominant container orchestration, but what about use cases for docker that simply doesn't need any orchestration? I mean those containers that are run on a single machine, perhaps manually, for purposes other than deployment?
zenexer 8y ago
I’m failing to see the argument here. The author suggests that the advent of viable Docker competitors will inevitably bring about Docker’s death. Why would that be the case? Competition is great, but it’ll be a while before others can match Docker’s maturity and ubiquity. Even then, there’s no guarantee that any of them will be better than Docker, never mind good enough to warrant switching. What’s wrong with Docker? Why would I want to switch to something else? Are these other solutions really so superior that they warrant the significant time investment that it would take for me to learn how to use them? The author doesn’t actually answer any of these questions. No arguments against Docker are made, nor are any arguments made in favor of competitors.
- baybal2 8y ago
  > What’s wrong with Docker? What's wrong with not using Docker? Outside of cloud/SOA/webscale sector, people having hard time to simply comprehend the drama. I have not seen any justification for using containers on any scaleable system on real hardware for example. In "ad-farm" world, running ad farms on pure hardware with netboot provisioning has been the "gold standard" since time immemorial. Few points: 1. Netboot with root at tmpfs takes less time to boot, seconds over 10G (most of the time is spent on POST and DHCP actually.) 2. Netboot images can be stripped to the barest minimum of life-sustainance. Less software running — less problems. 3. Less attack surface for hackers. 4. Hard lockup proof - hardware watchdogs are more or less foolproof. 5. Linkup to the real network is as simple as it gets, you can use broadcasts for self-configuration and service discovery on the network. 6. If you deal with RDMA, well, you will be already spending most of your efforts on just getting software work as advertised on the bare system, and the additional troubles of containerisation will not worth dealing with.
  - 1337shadow 8y ago
    Containerization is a cost effective alternative to building and running immutable VM images, which is a best practice in terms of CD. Another way to put it is: don't build in production, instead build in CI, test your image and then just deploy it on your environments (you probably should have at least two: staging and production).
fxfan 8y ago
I have an honest question- is docker even useful for most projects or is it just a preparation for solving imaginary scaling issues that most won't even reach? I ask because I'm wondering if I should care about docker in the beginning of my project which will have very few concurrent users/requests and would run fine on a single machine. EDIT: Thank you to all the kind answers!
- pknopf 8y ago
  The Docker CLI will be around for a long time. This post is just FUD. There isn't another runtime that is as easy to use as Docker.
  - macintux 8y ago
    The post was primarily about the company. The CLI can be around for decades, but that doesn't necessarily mean Docker the company can profit from it.
  - cpitman 8y ago
    Part of the article calls out how the alternatives (like CRI-O) are shipping docker compatible CLIs, so that users can keep going `docker build` but with a completely different runtime.
    - raesene9 8y ago
      CRI-O isn't comparable to Docker for developers, it's a replacement for Docker when used as part of a Kubernetes cluster. The thing is that whilst various operations are shipping bits of the functionality that Docker provides in various different tools, for developers working with containers none of them (that I've seen) have an easy to use, cross-platform setup.
- geezerjay 8y ago
  Docker is immensely useful when starting projects that use web services because it lets developer download and run instances of any service on demand with a single CLI command, and lets any teammember do the same with your work. Then with docker-compose you are able to instantiate custom deployments of your projects, including dbms and gateways and messa buses and IAM services, with a single command (docker-compose up). So yes, it's very useful. However, the point of the article is that Docker is no longer the only option, and although right now it's the default go-to container tool, there is nothing but inertia keeping the world using Docker.
pknopf 8y ago
The article mentions Kubernetes using containerd and the OCI is the future, but also fails to mention that containerd is developed by Docker, which supports OCI, which largely supported by the Docker company. As of the latest versions of Docker, the dockerd is now using containerd under the hood. I'm not sure how the Docker CLI will exactly die. The posts seem to focus on the CLI only, and even calls out that "the viability of the company Docker is outside the scope of the post", but it failed mention my previous points.
- scaryclam 8y ago
  Containerd is a project within the Cloud Native Computing Foundation, which in turn is part of the Linux Foundation. Docker haven't been directly involved since 2015, and even then, it's arguable that they've never been (you may be thinking of runc though, which was donated in 2015). It's true that Docker uses containerd under to hood, but that's actually part of what the author is arguing. Docker as a technology is a wrapper platform around core industry technologies that they neither own or control. That means they have to compete as a tooling company, and they have already lost ground there. The more things like Kubernetes and podman join the market, the less required Docker becomes, which means they're going to be more and more at risk of failing. https://en.wikipedia.org/wiki/Linux_Foundation#Containerd https://en.wikipedia.org/wiki/Linux_Foundation#Containerd edit: added link for reference
  - pknopf 8y ago
    > Docker haven't been directly involved since 2015, and even then, it's arguable that they've never been A large majority of even the recent commits to containerd are made by Docker employees. https://github.com/containerd/containerd/commits/master https://github.com/containerd/containerd/commits/master > It's true that Docker uses containerd under to hood, but that's actually part of what the author is arguing. Docker as a technology is a wrapper platform around core industry technologies that they neither own or control. I cede your point, but it's irrelevant and isn't want the author implying (even directly). From the article: "I do not think there is any reason for us to user docker any more and therefore Docker as a technology and as a company will slowly vanish." The end users do not care how cgroups are setup or mount points are built. The guts may be standardized, but the docker toolchain (Dockerfile, docker-compose, docker run) will continue to exist. The "runtime" is irrelevant and there just isn't a competitor in the "tool chain" arena. Docker Swarm is the only thing that will vanish. > The more things like Kubernetes and podman join the market, the less required Docker becomes, which means they're going to be more and more at risk of failing. Kubernetes is an entirely different use-case. Nobody is arguing Docker Swarm will beat it. You could say the Docker CLI isn't required with the advent of other tools, but those are incredibly big shoes to fill. Think of all that entails (Dockerfile, docker-compose, the CLI, cross-platform(-ish) support for Windows/OSX). Also, competition leads to better tooling. Did anyone ever say "Unix isn't required any more, because with have Linux"? The tooling of the Docker CLI is in a very good spot as-is. The guts are being opened, which I think would relieve the pressure some may feel to jump from Docker.
nathan_f77 8y ago
Are there any container filesystems that support multiple inheritance, and create diff layers? It would be really nice if I could build a few different things independently, and then merge the final images together. Also if I could only include files that have changed in a new layer, and ignore duplicate files (even if the file was touched, or the timestamp has changed.) Those are my biggest pain points with Docker at the moment. I have a complex build script that uses multi-stage builds and rsync to achieve this [1], but it's still a bit slow and inefficient. Would be nice if something supported this out of the box. I've worked on a lot of projects where people just reinstall (and recompile) their entire list of dependencies (Ruby gems or NPM packages), and you have to jump through hoops to set up a caching layer, or maybe install them into a volume as a run-time step, instead of at build time. There should be a much better native solution for this, instead of needing to invent your own thing or read random blog posts. [1] https://formapi.io/blog/posts/fast-docker-builds-for-rails-and-webpack/ https://formapi.io/blog/posts/fast-docker-builds-for-rails-a...
- narrowband 8y ago
  That sounds somewhat like my current project [0]. Currently it's in the prototyping phase, so it won't be released for a while, but it's coming along nicely. Your use case is one I've been planning to support all along, although I think about it a bit differently - in terms of composition of (partial) images rather than multiple inheritance. [0]: Dev blog: https://www.narrowband.org.uk/ https://www.narrowband.org.uk/
- Nullabillity 8y ago
  Nix[0] does this, sort of. It doesn't merge everything into one tree at runtime, but instead builds every package to a unique path, which gets embedded into downstream dependees. It assembles the dependency tree into a DAG, and uses this to automatically parallelize builds (where safe). Builds automatically run in ephemeral containers, to ensure that all dependencies are accounted for. There are also importers for many languages, and an exporter for Docker images (where each Nix package becomes one Docker layer, up until a limit that you specify). [0]: https://nixos.org/nix/ https://nixos.org/nix/
- cpuguy83 8y ago
zmmmmm 8y ago
> When people understand that they can easily make the choice to swap out the container runtime, and the knowledge is out there and easily and readily available, I do not think there is any reason for us to user docker any more and therefore Docker as a technology and as a company will slowly vanish How about MySQL as a counter argument? It's always been feature-weak compared to PostgresQL, with a less business friendly license and now owned by one of the most despised software companies by technologists. But it's probably still the default relational database people pick up. Habit, defaults and massive installed base can go a long, long way.
- kikoreis 8y ago
  You are right, but it is hard to see how for profit Docker Inc benefits from that. MySQL had a business model that was similarly challenging, which lead to where it is today.
  - user5994461 8y ago
    MySQL has a strong ecosystem model and it's a pain to switch databases. Young developers used to get a LAMP stack, Linux Apache MySql Php and that comes with MySQL. There are many products, one could say even languages, that require MySQL. The database is the hardest component to switch and even if the company were to disappear today, it would take decades to migrate off. Docker has none of this. It only happened a few years ago, it will be gone as quickly. It doesn't even have a strong brand name, people want kubernetes not docker, docker is merely a dependency that can be replaced.
    - kikoreis 8y ago
      Yeah, I agree. MySQL was in a more robust position, and even then the outcome was disappointing. Open source business is tough.
- imhoguy 8y ago
  Container engine is just a wrapper around couple of Linux APIs mainly cgroups & namespaces & iptables/BPF - there is most of hard work done. A good example how trivially it can be implemented is this: https://news.ycombinator.com/item?id=9925896 https://news.ycombinator.com/item?id=9925896 Now, implementing DBMS with even basic SQL query language, is not a trivial job.
McDonaldized 8y ago
In this thread, we resist the reduction of complexity, to the effect that job security is maintained, such that our careers are not commoditized by McDonaldsization.
codegaucho 8y ago
Who is providing a container registry that can replace the offering from Docker (the company)? That seems to be the big contribution of Docker the company these days: a huge library of container images.
- itomato 8y ago
  ..that have stagnated and are now riddled with vulnerable components.
  - zapita 8y ago
    Really? The official images have been quite solid and up-to-date in my experience. Has that changed since last year?
sheeshkebab 8y ago
Docker should just merge with Npmjs. Then they might get big enough to get bought up by Microsoft, Oracle or IBM (which I think is their end game anyway).
rcdmd 8y ago
Nope. Docker's value isn't just its software. It's the support built around it, tutorials, familiarity and common usage, Dockerfiles, huge Docker Hub, existing setups relying on it and so on. Articles like this tend to overlook the value of entrenched technology that works well enough.
- user5994461 8y ago
  Funny enough. Kubernetes ignores pretty much all of that in favor of its own, making experiences in running Docker alone mostly worthless.
rleigh 8y ago
I do like the fact that docker now works for non-Linux cases, like Docker on Windows with Windows containers. Would be nice if they would also support MacOS containers, FreeBSD etc. That would certainly entrench themselves as a "universal" container technology.
wwarner 8y ago
I basically agree with the technological argument made in the post. Orchestration plays the role of OS, where resources are defined, managed and protected. Containers are something analagous to device drivers, presenting the underlying resource as narrowly and efficiently as possible. But that's the life I expect, not the one I live today. In the present day I'm much more reliant on docker than on kubernetes, and I cannot live without being able to freely mix and match go, python, or Java , really old and really new, in any host configuration I want.
languagehacker 8y ago
It's not clear to me that the author has a solid understanding of how Docker makes it money. You don't make money just by giving away software, and you also don't make money by providing support software for no one uses. Docker has been pretty smart to build a well-known brand around supporting a specific set of technologies -- some theirs, and some not. When it became clear they were unable to own every part of the container ecosystem, they made smart decisions around supporting k8s and engaging the open container standard. Docker's got lots of runway providing enterprise support contracts, so I'm not worried about them. I think the author's also not noticing that orchestration was really a bit of a stumbling block that would eventually be removed. Sure, you've still got to use k8s in self-hosted, GCP, and Azure, but those of us on AWS have the option to use ECS with Fargate and have many of the core features of something like Kubernetes fully managed. So anyway, this post is a bit dramatic, and maybe has a few blinders on.
tobbyb 8y ago
What is wrong with Docker? This does not address any technical or other shortcoming and only seeks to replace one set of over engineered tools with another with the exact same problems. [1] The is yet more of the ecosystem continuing to push over engineered tooling and 'winners' breathlessly without basic technical scrutiny that leaves end users dealing with needless complexity and debt. Containers can be useful as a lightweight, efficient alternative to VMs and those who want containers untouched by questionable ideas should try the LXC project on which all this was based. Any additional layer on top of this be it non standard OS environment or layers should meet technical scrutiny for end user benefits and most users will be surprised by the results. [1] https://www.flockport.com/guides/say-yes-to-containers https://www.flockport.com/guides/say-yes-to-containers
Aeolun 8y ago
Yeah, no. Docker is still here and is finally being embraced by larger enterprises (if they haven’t already). I don’t see it being switched out for any unproven technology any time soon.
EliRivers 8y ago
Docker was the company that changed the world I think I've seen one person use docker once, back in about 2013, to create and freeze a very particular Latex setup. Everybody sees a tiny slice of the world, but to each individual, that slice looks like all of it.
- itomato 8y ago
  How many people have you seen printing money?
  - EliRivers 8y ago
    Yes, I need to speak more simply, for the kind of HN commenter who revels in minutiae and takes pleasure in ignoring meaning to pursue literality and arguments about arguing. Unless you want to argue that the invention of money and the invention of docker have had comparable effect on the world? Go on, now push your hypothetical spectacles up along the bridge of your nose and say "Ah, ah, I said 'printing' of money!"
windexh8er 8y ago
The death of Docker could potentially happen, but not for the reasons the author lays out. The last argument in the article is interesting. The author implies because RHEL dropped Docker - then game over. But if we want to analyze this it isn't because Docker lost a technology battle. It's because RHEL is protecting their ecosystem. The article is correct in making the case there is choice. However the author doesn't put two and two together with regard to RedHat. Just because you can alias podman with docker doesn't really mean anything. Someone seems to have dipped into the non-reality of Docker-is-a-bad-word, by author Dan Walsh of RedHat. Also keep in mind containerd was contributed by Docker and is the graduated runtime in CNCF. You definitely don't need Docker to run containers. But it's easy to use Docker to run and build. And Docker is still a one line installation on all Linux platforms (https://get.docker.com https://get.docker.com) Next is Docker Enterprise. Can they sell it? This is where Docker is making mistake after mistake IMO. Docker does have a leg up in Windows. But does it matter? Today Swarm is your only orchestration option and while I understand k8s support is coming it still remains to be seen if GMSA is included in the first release (doubtful). If you're a Windows developer and you're deep in the Microsoft ecosystem, you won't be able to productively use Windows Server and k8s this year is my guess given the timelines. Regardless, Docker has done a poor job capitalizing on Windows. Maybe it's that people just don't need it as much as Docker would have you to believe? Or maybe it's too jarring of a workflow change. Regardless, it isn't working. Next is the products you get for the money: Docker Universal Control Plane (UCP), Docker Trusted Registry (DTR) and Docker Enterprise Engine (EE). They're all OK. But the sell is, again, tough. UCP is basically a dashboard for centralizing RBAC for Swarm and UCP in the enterprise, and don't get me wrong - the enterprise needs this. But UCP feels lacking. The UI is distracting and has a lot of oddities. Managing it is a decent amount of work. It's just OK. Also Docker UCP still doesn't support k8s PaaS while competitors do. Remember that Docker hired Kal De away from VMW as CTO. In his time at Docker not much has changed externally, but Docker needs to move faster. Much faster. DTR is interesting because everyone who's doing containers in the enterprise needs an image repository with, again, those enterprise requirements. And DTR delivers this, but Docker doesn't want to sell you DTR only. You can't buy DTR by itself like it's competitors. Docker wants you to only use all of their bits and it's dumb because Docker claims choice as a core pillar then tries to lock you into UCP+DTR+EE. Oh I see Steve... Choice as in what DOCKER defines for me as choice. Choice of bare metal or hypervisor, but not how I manage containers and orchestration? Back to DTR: it's decent, but again there are other choice and a lot of them are better standalone offerings. Finally EE. There are about three reasons you really need EE. The first is enterprise support and long term releases. The second is runtime enforcement of signed images at the engine level. The third is oddities like FIPS support. But that's it. And, again, Docker doesn't want you to buy just Engine. They want to sell you the 'platform'. At the end of the day Docker has good products. They're not exceptional when taken into context of other enterprise software. They're just OK. Docker doesn't realize this yet from what I've gathered. They have recently changed pricing to very VMW-esque CPU count pricing. And Docker doesn't have the market capital to make that leap, unfortunately. At the end of the day my opinion is that Docker is marred by Docker. Not by the competitive landscape. Yes, that contributes to Docker overall but Docker doesn't seem to make sure they have the best product above everything else. Docker's CEO, Steve Singh, is the wrong guy for the job. He is constantly stating cash flow positive by end of this fiscal year yet doesn't seem to care about how good or bad the product actually is or why people wouldn't buy Docker over something else. So yeah... Docker has done great things. Those great things are all of the contributions Docker has made to the community and continues to do so. But Docker on the enterprise side feels weak, lackluster and very confused. Docker is marred by Docker management and executive ranks from within. I'll give them 2 years make or break and I think, as it stands today it's a coin flip. The acquisition of RedHat by IBM was a good thing for Docker, but may be the nail in the coffin for RHEL long term. If Docker does flounder any longer look for them to be acquired by Microsoft. And then... Docker will be set to sail off into the ether.
nisa 8y ago
I'm using Swarm on a small cluster (3-5) machines. Is there any reliable Kubernetes alternative for that? Portainer as Swarm UI was buggy for me - a usable and stable UI would be nice, but I'm not sure if I should do the full Kubernetes dance :/ Easy to debug and lightweight would be also great. I didn't really found something good.
- tpetry 8y ago
  Almost all non kubernetes docker solution seem to be no longer maintained. But nomad is alive and has interesting concepts.
- ofrzeta 8y ago
  It's not like Kubernetes has a better UI. You could take a look at OpenShift. It's a Kubernetes based Open Source distro my Red Hat and it includes a quite nice UI, both for users and admins.
- GordonS 8y ago
  I'd be really interested to know more about your setup and processes if you're running Swarm in production? For example, how do you handle rolling updates?
  - nisa 8y ago
    we are not a SaaS company, we just run some simple nodejs based services on swarm and my goal is to use swarm as a testing hub for docker - mostly the ci should push something there for the devs. So uptime does not matter, however swarm crashed badly a few times on me and at the moment everything important is well configured outside using your typical LTS linux distribution and I'm hesitant to move our basic services to it...basically 9-5 it has to work, I can just run apt-get update && reboot earlier or later - really not sure if I should move all the stuff into swarm / k8s - also because bus factor would be one and there is some experience with the old linux way. For everything that resembles a microservice/service -> Docker, everything else (ldap, mail) -> oldschool. So far so good. I'm looking at k3s or minikube with rancher as ui - maybe that's better, or we just ignore the hype and run docker-compose.yml files by hand but that's also pretty shitty.
auslander 8y ago
> .. All the cool kids on the block are no longer using docker as the underlying runtime. Cool kids are not using containers at all, they use cloud VMs and autoscaling :) Simple is not easy (tm)
hartator 8y ago
The main thing is Docker has been used as a way to distribute binaries with all dependencies builtins. Bypassing all OS packaging systems. It’s a hack on top of our broken packaging models. That does work but it is extremly fat and not very elegant.
MindTooth 8y ago
Based on this, I've tried most of today to make minikube work on macOS. But as I'm using DNSCrypt-Proxy I had major issues making it work without manual steps. So far, the Docker for Mac is a solution that just works. If someone have some experience, I'll gladly want to know how you make it work flawless.
btbuildem 8y ago
Since the author doesn't name any of the alternatives: https://containerjournal.com/2019/01/22/5-container-alternatives-to-docker/ https://containerjournal.com/2019/01/22/5-container-alternat...
ofrzeta 8y ago
I don't get why not more people are using Swarm. It's simple and it get the job done for many people who don't need a full Kubernetes setup. Also, for instance, it encrypts secrets, opposed to Kubernetes which only does Base64 encoding of secrets. I do understand the market dynamic but still there are niches for other simpler products.
- dankohn1 8y ago
  Kubernetes supports encryption at rest of secrets: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ https://kubernetes.io/docs/tasks/administer-cluster/encrypt-... They're encrypted in transit via mTLS.
CWuestefeld 8y ago
All 3 big cloud providers, now have a managed Kubernetes solution that they offer to their customers (and as a result will eventually sunset their own home-made solutions that they built over the years - because there can be only one). I haven't heard anything about this from AWS. Certainly they've introduced EKS, but I haven't heard anything about setting their ECS orchestration out to pasture. Does anybody have information about this?
peterwwillis 8y ago
This is sad, because what made Docker useful was a full feature set. We could already build chroot environments. We could already keep remote images. We could already set up app-specific networks. Having the tools wasn't what we needed: it was the confluence of all the features. If the alternative to Docker becomes learning 50 new tools, we'll have failed as an industry, and shouldn't call ourselves engineers. You don't replace a car with a wheel barrow-lawn mower-hand held radio-portable fan. This obsession with churning out a new tool every year has to stop.
miguelmota 8y ago
Yea there are alternative Docker runtimes and Kubernetes won the orchestration war but Docker images are here to stay. As far as I know there aren’t better alternatives for Docker images and even Kubernetes uses Docker images. Docker as company currently has a Red Hat-like business model and that’s certainly hard to sustain so agree on that front.
Rafuino 8y ago
Are Kata and Clear containers actually a Docker replacement?
- raesene2 8y ago
  Not really. They can be used to replace one element of the docker stack, runc
ilaksh 8y ago
What do you replace Docker Hub with?
williesleg 8y ago
Just another FUD hit piece.
thruhiker 8y ago
I've always disliked articles that use this tone. It's meant to be informal, but comes off as lazy and spoken in muted tones as if the author were in a pub; Docker sitting in a booth a few meters away blithely sipping on a pint of bitter. The substance isn't much more enlightening than typical bar banter either. Docker played a pivotal role in creating our modern understanding of containers and we should be thankful for that. I don't understand the value this article provided beyond pointing out a few container runtimes I hadn't heard of.
redsavagefiero 8y ago
Still using LXC where it makes sense and never felt the call of Docker...or Kubernetes or any of this developer popularized opaque tooling over sophisticated meddling with my systems.

378 points by Corrado 8y ago

yuriko 8y ago

Dupe of https://news.ycombinator.com/item?id=19350571 https://news.ycombinator.com/item?id=19350571

tomhoward 8y ago
It's not a dupe if the earlier submission(s) got few/no comments/upvotes.

gfiorav 8y ago

So many times have we thought that a technology will prevail or disappear based on its validaty or adequatecy, and so many times have we seen the most popular survive. JavaScript comes to mind. If it’s widespread and easy to learn, it might not matter how much technically better other alternatives might be. We’ll see

tcd 8y ago
"BuT jQuEry iS DeaD!?!"

raesene9 8y ago

It's fair to say that in the hype cycle Docker (the technology) has passed its peak, but I don't think the conclusion that as a technology, it's finished, is warranted. Containerization is still on the rise and Docker is part of that. The toolset is still a good, fairly easy to use, place for individual developers to use containers on the client-side whilst creating containerized applications. For smaller deployments (without orchestration) a single Docker engine with things like compose, can still work well. Obviously on the orchestration side, Kubernetes has won, although it too will face the inevitable trough of disillusionment when people realise that all technologies have downsides. Personally, for simpler workloads, I think Docker swarm can still be a good answer, as it's a lot less complex than Kubernetes to set-up and maintain. The idea that the Redhat container stack (podman, CRI-O, et al) necessarily mean the end of Docker, doesn't really follow at all to me. If anything the increased use of containerd directly is a bigger threat to Docker's market share.

wodenokoto 8y ago
I think the main point to consider is, if Kubernetes is the technology for large deployments, who is left to buy enterprise solutions from Docker the company? And without enterprise sales, what is going to fund docker development for the small and simple docker workloads?
- raesene9 8y ago
  Well Docker the company is a different game. They have gone quite heavily for the enterprise market and support Kubernetes as part of their Docker EE product. Of course, whether that will give them enough success to justify their valuation, is another matter. Personally, I had thought they would get bought out by one of the large tech. players who is heavily investing in containerization (e.g. Microsoft) but that doesn't seem to have happened so far.
  - pbalau 8y ago
    Amazon might have a say in this, both their ECS and EKS solutions are based on docker.
- pknopf 8y ago
  The Docker company may not survive, but Docker will. Especially considering the work the Docker company is doing to support OCI. The dockerd internally uses containerd now, which supports both Docker images and OCI images.
  - alexandre_m 8y ago
    I always tend to think that the reason Docker developers decided to split the Docker products codebase (CE/EE) into the Moby components 2 years ago was that they foresaw the inevitable death of Docker in the long-term.
user5994461 8y ago
>>> It's fair to say that in the hype cycle Docker (the technology) has passed its peak, but I don't think the conclusion that as a technology, it's finished, is warranted. That's confusing the product and the technology. The technology is containerization, not Docker. Containerization is on the rise and will continue. Docker as a product AND a company, is doomed. They have no business model and no sales. All of Google/Amazon/RedHat/Linux are working on a substitute so they don't have to depend on it. The hype is in Kubernetes now and managed cloud solutions. Docker is an accidental dependency of Kubernetes, until it's finally get rid off.

mickeyp 8y ago

A shame, really, but not a huge surprise that products like Swarm fell by the wayside. I feel it could've occupied a nice middleground for teams that didn't need the full capabilities (or overhead of supporting) Kubernetes, even though I think K8s is an exceptional project. I chose Swarm as a pragmatic choice in an enterprise environment that didn't have any prior experience with Docker at all, really, at the operational level. We had to support financial models, often many different versions of the code at the same time, on top of the usual stack of applications to go with that. The choice was a "success", albeit one muted by the wacky networking layer they use. Compound that with RHEL's older kernels, and we had to deal with oddball issues like iptables/arp table getting out of sync with what's actually running, resulting in connectivity issues. And don't get me started on removing and redeploying a stack; that would occasionally wedge things so badly we had to cycle the docker daemon. Still, a shame. The gap between "Look, I wrote a compose file" and running something on a small cluster is tiny, and that was its main strength, even if it did suffer from some serious heisenbugs. Why they decided to add and remove features between versions and do their damndest not to make a compose file 100% "forwards compatible" with Swarm is another mystery.

usgroup 8y ago
Swarm was a pretty big mistake. I think based on just relative resource investment compared to Kube, it ought to have been obvious that it’d never be relevant if it wasn’t extremely specialised.
- mickeyp 8y ago
  That's true. However, consider this environment: - The ops team are in a different country, and are wedded to very old-fashioned views of administration ("Automation? But I like manually running commands from a runbook!") - You work with a team of people who are quants/actuaries/scientists/engineers but not professional developers, but you want them to have a turn-key environment so they can Get On With It. When they need new python packages or god forbid upgrade pandas or something else, there's a full CI chain that'll make sure that what they do here also works there. - Swarm is (from personal experience) easy enough to teach people who don't know anything about Docker. You can show them how to query the state, modify it, look at logs, etc. all without the hassle and overhead of configuring and running K8s, even though it will always be my #1 choice for tech-literate orgs. Swarm, for many, including myself, was a pragmatic choice -- 80% of the immediate benefit of container orchestration with 20% of the cognitive overhead for the chaps in another country who had to maintain it if things went south.

vbezhenar 8y ago

For me Docker's value is to be able to easily run some Linux services with Windows. They got a lot of ready to use recipes on their website, so it's really easy to run e.g. wordpress with mysql. I would spend at least hour to manually setup VM with Ubuntu, install that stuff there. Also I'm using it to run postgresql for development. While technically I can do it just from Windows, I feel safer concentrating all that stuff inside disposable VM, also it's easy to share onboarding scripts with colleagues. I don't see how RHEL's tools would help me with that. Actually I could replace all my Docker usage with few shell scripts, but they have to be written and with Docker they are already written, many by experienced software maintainers. Docker will die when popular software will discontinue their docker images.

ndnxhs 8y ago
For me docker is a really convenient way to self host multiple services on one host. In the past I did it without docker and almost every service requires you to add a repo and after you do this a few times you almost always end up breaking your system and having to start again. Docker keeps things clean and easy to manage.
fxfan 8y ago
How's docker on Windows working out for you so far?
- vbezhenar 8y ago
  No problems at all. There was weird problem when I tried to output binary file to stdout inside docker and redirect it inside cmd which resulted in garbage. But it wasn’t appropriate usage I guess.

tnolet 8y ago

This is a similar discussion to vinyl vs cassette vs cd vs streaming. All will keep existing in some form or another. Admittedly, some will die out completely (DCC, Minidisc) I’m pretty skeptical this going to be Docker though. Even more, the argument that because Redhat RHEL 8 no longer has a Yum repo for it Docker is dead in the water is a bit far fetched. According to Wiki RHEl is a fairly small % of the server market compared to Ubuntu, Debian and Windows for that matter. https://en.m.wikipedia.org/wiki/Usage_share_of_operating_systems https://en.m.wikipedia.org/wiki/Usage_share_of_operating_sys...

jgillich 8y ago
RHEL also means Fedora and CentOS, the latter is extremely popular for large scale deployments. The article is for web servers only, I think the real market share of RHEL and CentOS is more like 30-40%. Podman just makes more sense because it doesn't require a big fat daemon. You launch containers like any other service: with systemd. And you can run podman without root permissions as well, which is a huge win for security.
- tnolet 8y ago
  Well, having worked quite a bit with RHEL and Centos in the past, I found their day to day usage quite different. Maybe that has changed. More important, I only saw RHEL at traditional Fortune 500 companies. Not sure how their market in FANG type companies is. Probably negligible. F500 is still big of course.
  - user5994461 8y ago
    FANG are making their own OS at this point so they're not really relevant. There are two distributions left in Linux, RedHat derivatives and Debian derivatives. In terms of install base, it's maybe 1/3 and 2/3. In terms of money, expect the other way around, because it's F500 who pay the most for software and they are on RedHat. RedHat is actively trying to kill docker (along Google and Amazon). RedHat removing "docker" CLI and replacing it with its own tools is a major step toward that. Docker will be de facto dead in enterprise as soon as it stops being supported by RedHat.

deleted 8y ago

[deleted]

leowoo91 8y ago

It's just normalized as any other technology, it doesn't mean company is not ready for it but that's up to how much they've been partying since.

maaaats 8y ago

This article contains really no good reasons and spends many words to say that unnamed alternatives exists. One argument is that there are no new big features. But that is completely normal when things become stable.

cwingrav 8y ago
Agreed. I came for rational but saw none. There seems to be a lot of hate for Docker I don’t understand. Is it community management? Is it some esoteric tech concern? Can someone more knowledgeable pipe in?
- pknopf 8y ago
  I agree. Why do people hate Docker, the CLI. Anyone? I mean, it's slowly going OCI, so no vendor lock-in.
  - pxtail 8y ago
    HN crowd likes to gaze at FANG-like corps and treat it like gods, FANGs use Kubernetes? well then for sure docker is passe :) It doesn't matter that for some use cases swift and straightforward solutions like docker and it's ecosystem are better.

std_throwawayay 8y ago

Providing base technology doesn't seem to lead to financial success. You have to provide more concrete solutions for companies and people instead of the abstract infrastructure. I wonder if protection of the base technology through software patents could have averted this looming financial disaster.

mixmastamyk 8y ago
Prior art existed for a decade.

danieldk 8y ago

This post links to podman. But the podman website is completely useless, because it does not tell me what it does differently/better than docker, only that What is Podman? Simply put: `alias docker=podman` So, for someone who occasionally uses Docker for running services or creating specific build environments (manylinux1): what are the benefit of podman over Docker?

rmk2 8y ago
Podman doesn't have a daemon like Docker does. It also more tightly integrates with buildah, which the article doesn't expand on. Have a look at this (very brief) overview to get a bit better idea of their relationship: https://github.com/containers/buildah#buildah-and-podman-relationship https://github.com/containers/buildah#buildah-and-podman-rel... Podman also uses the same notion of pods, and it doesn't support docker-compose syntax/files, because RedHat strongly believes that Kubernetes has already won. Basically, podman/podlib allow you an easy migration path from your local computer to a k8s cluster, with the same images and same concepts. Have a look here: https://github.com/containers/buildah#buildah-and-podman-relationship https://github.com/containers/buildah#buildah-and-podman-rel...
- nirv 8y ago
  > Podman also uses the same notion of pods, and it doesn't support docker-compose syntax/files, because RedHat strongly believes that Kubernetes has already won. Could you expand on that please? Almost everything I run locally (be it a self-hosted service or app devel) with docker is a docker-compose stack. It allows me to easily manage/monitor services via CLI or Portainer. How does Podman and other modern tools offer to solve this case, or is it proposed now to use K8s locally? I got enthusiastic about Podman not having a daemon and running Podman containers as a non-root user[1]. [1] https://opensource.com/article/18/10/podman-more-secure-way-run-containers https://opensource.com/article/18/10/podman-more-secure-way-...
- detaro 8y ago
  The second link is the same as the first, did you mean to put a different one?

oftenwrong 8y ago

s/Goodbye/So Long/

raverbashing 8y ago

As much as docker works, I can't help feeling it is a big kludge. CLI usability is close to zero. One (temp) image per line in the Dockerfile might have some practical uses, but most of the time it doesn't. Yes it seems their days are numbered.

pknopf 8y ago
> CLI usability is close to zero What? > One (temp) image per line in the Dockerfile might have some practical uses, but most of the time it doesn't. I completely disagree. Cached builds being one reason, viewing the intermediate layers is just a huge benefit. Why don't you like it. You could always build with "--no-cache", which all CI should be using anyway.
- raverbashing 8y ago
  > What? Yes. It's all over the place. https://docs.docker.com/engine/reference/commandline/cli/ https://docs.docker.com/engine/reference/commandline/cli/ It has no obvious separation of commands dealing with images/containers/running containers. Sometimes you refer to them by tags, sometimes by IDs. It's non discoverable. It's non intuitive. I can't know what 'docker rm' does without reading the docs. Oh and there is 'docker rmi' is that for images? Docker build has this nice example here: '--tag , -t Name and optionally a tag in the ‘name:tag’ format' Ok so you set a name with --tag? Compare with 'kubectl get pods' > Cached builds being one reason, viewing the intermediate layers is just a huge benefit. Sure, as I said, it is useful, but you do not want to do this most of the time. > You could always build with "--no-cache", which all CI should be using anyway. Bad defaults are an UX problem, thanks for furthering my point.
  - declnz 8y ago
    >It's non discoverable. It's non intuitive. > I can't know what 'docker rm' does without reading the docs. Oh and there is 'docker rmi' is that for images? I think you're using the old CLI. A couple of years ago, they added new syntax and "encouraged" its use by default [1] (though IME people still use the original). This is definitely more discoverable and logical; the syntax would be `docker image rm` [2] or `docker container rm` [3], etc [1] https://blog.docker.com/2017/01/whats-new-in-docker-1-13/ https://blog.docker.com/2017/01/whats-new-in-docker-1-13/ [2] https://docs.docker.com/engine/reference/commandline/image_rm/ https://docs.docker.com/engine/reference/commandline/image_r... [3] https://docs.docker.com/engine/reference/commandline/container_rm/ https://docs.docker.com/engine/reference/commandline/contain...

WestCoastJustin 8y ago

The death of the Docker as a technology is laughable. Every Cloud provider is racing to add container orchestration features and they all use Docker under the hood [1, 2, 3, 4]. Cloud providers are dumping hundreds of millions into this ecosystem through, training, credits, new features, etc. I have not seen anyone step off the gas. They are all seeing massive growth in container adoption. My guess is this is only the start. Go look at any DevOps/SRE job posting and you will see Docker, Containers, Kubernetes. This post is wrong when is comes to the technology going away anytime soon. Container orchestration is light years better than anything that we were doing on the operations side before. This is why I find it extremely hard to believe we are going back. We would need something much better to jump to and that has not been invented yet. So, Orchestration/Docker/Containers are here to stay for the foreseeable future. The rkt image format tried early on to subvert the Docker Image format and was unsuccessful. Today, there is much more depending on the existing image standard. You would totally fragment the existing integrations if you attempted to change. I am not saying that people will not try. But, I just cannot see it happening anytime soon. You have all these Clouds betting on it, you have millions of Dockerfiles out there now, and tons of people trained on it. All these CI/CD platforms supporting it. You would need some massive reason to change. Why would they? You might see people under the hood take the Docker Image and wrap it somehow, like gvisor [5], but they will still likely accept the Docker Image. Go look at these charts from Datadog about their customers Docker adoption [6]. Every single chart is hockey stick growth. This is a sampling of 10,000 companies running 700 million containers in real-world use. I am just offering a counter to the point that the image format is coming to its death. I do not see that. Disclosure: Former Docker employee. [1] https://aws.amazon.com/ecs/ https://aws.amazon.com/ecs/ [2] https://aws.amazon.com/eks/ https://aws.amazon.com/eks/ [3] https://cloud.google.com/kubernetes-engine/ https://cloud.google.com/kubernetes-engine/ [4] https://docs.microsoft.com/en-us/azure/aks/ https://docs.microsoft.com/en-us/azure/aks/ [5] https://github.com/google/gvisor https://github.com/google/gvisor [6] https://www.datadoghq.com/docker-adoption/ https://www.datadoghq.com/docker-adoption/

nebulous1 8y ago
He isn't saying containers are dying, he's quite clear on that.

gulikoza 8y ago

I never understood why "modern" tools like Docker have to provide everything: networking, firewall, repository, you name it... I understand somebody wanting to type "docker run xxx" and have everything setup automatically, but if you're running anything but default networking and actually care where the xxx image comes from, it's gonna fail miserably. Coming from the VM world, I found it much easier to work with macvlan interfaces that lxd supports for example - the container gets it's own interface and IP address and all networking can be prepared and set up on the host instead of some daemon thinking it knows my firewall better than me...

empath75 8y ago
Because most people don’t know anything about networking or firewalls and don’t want to.
- fatherlinnux 8y ago
  Most people nothing about technology and don't want to. Not sure where that argument goes, but I am guessing jobless...
snidane 8y ago
Yeah, it feels too monolithic. Just to showcase it can run Hello World in one "docker run" command I guess? Another thing people use Docker for but shouldn't is application packaging. Using Docker you build one fossilized fat package with both all OS and app dependencies baked in. Then some day after years of using that Docker image you need to upgrade your OS version in the image but you can't replicate the app build because you didn't pin exact library versions and the global app repository's (pip, npm) later version of the package is no longer compatible with your app. Application packaging is better to be done in proper packaging systems like rpm od deb or other proprietary ones and stored in organization's package repository. Then you can install these rpm packages in your Docker images and deploy them into cloud. The difference in OS dependencies and app dependencies are clear when looking at contents of actual dockerfiles. OS dependencies are installed leveraging rpm or deb ecosystem. Apps are cobbled together using a bunch of bash glue and remote commands to fetch dependencies. Why not use proper packaging for both OS and apps and then just assemble the Docker image using that?

polskibus 8y ago

Honest question from someone who only used docker on several occasions to deploy 3rd party software but wants to invest into containerization. Is it worth going deep into docker right now? Is he knowledge transferrable to kubernetes and whatever else is going to replace it? I want easy deployment that properly deploys containers and telheir dependencies, but many of my scenarios don't need redundancy, scalability etc. My use cases are in-house so managed solutions won't be considered. On the other hand I don't want to have much worse operational complexity than with docker (and that's what I heard running local kubernetes biggest drawback is). Also many open source solutions provide dockerfiles, not caring about other containerization solutions. Please help, I'd rather avoid investing in an already obsolete solution if possible.

aboutruby 8y ago
docker-compose is quite Docker specific but the underlying concepts and the commands used in a Dockerfile can be used on any kind of setup
raesene9 8y ago
Docker the technology isn't obsolete now and I very much doubt it will be in the future. As you've noticed there's a load of solutions who make use of Dockerfile formats and store images on Docker hub. I'd expect that there will be future developments, but that they'll be backwardly compatible with existing deployments. Docker Engine (the daemon running on a single host) and Kubernetes (the orchestration system) largely serve different needs. Kubernetes is good for large scale deployments where it's additional complexity is warranted. For running groups of containers on a single host (or small number of hosts) Docker does just fine.

sbhn 8y ago

If you are a coder, and you want to implement auto devops yourself, for free, then see this video. https://youtu.be/Qlj6NiOy5jM https://youtu.be/Qlj6NiOy5jM You can do it to, remember the proffesionals will shout at you for using this method, it makes them obsolete.

kccqzy 8y ago

Well I can see kubernetes being the dominant container orchestration, but what about use cases for docker that simply doesn't need any orchestration? I mean those containers that are run on a single machine, perhaps manually, for purposes other than deployment?

zenexer 8y ago

I’m failing to see the argument here. The author suggests that the advent of viable Docker competitors will inevitably bring about Docker’s death. Why would that be the case? Competition is great, but it’ll be a while before others can match Docker’s maturity and ubiquity. Even then, there’s no guarantee that any of them will be better than Docker, never mind good enough to warrant switching. What’s wrong with Docker? Why would I want to switch to something else? Are these other solutions really so superior that they warrant the significant time investment that it would take for me to learn how to use them? The author doesn’t actually answer any of these questions. No arguments against Docker are made, nor are any arguments made in favor of competitors.

baybal2 8y ago
> What’s wrong with Docker? What's wrong with not using Docker? Outside of cloud/SOA/webscale sector, people having hard time to simply comprehend the drama. I have not seen any justification for using containers on any scaleable system on real hardware for example. In "ad-farm" world, running ad farms on pure hardware with netboot provisioning has been the "gold standard" since time immemorial. Few points: 1. Netboot with root at tmpfs takes less time to boot, seconds over 10G (most of the time is spent on POST and DHCP actually.) 2. Netboot images can be stripped to the barest minimum of life-sustainance. Less software running — less problems. 3. Less attack surface for hackers. 4. Hard lockup proof - hardware watchdogs are more or less foolproof. 5. Linkup to the real network is as simple as it gets, you can use broadcasts for self-configuration and service discovery on the network. 6. If you deal with RDMA, well, you will be already spending most of your efforts on just getting software work as advertised on the bare system, and the additional troubles of containerisation will not worth dealing with.
- 1337shadow 8y ago
  Containerization is a cost effective alternative to building and running immutable VM images, which is a best practice in terms of CD. Another way to put it is: don't build in production, instead build in CI, test your image and then just deploy it on your environments (you probably should have at least two: staging and production).

fxfan 8y ago

I have an honest question- is docker even useful for most projects or is it just a preparation for solving imaginary scaling issues that most won't even reach? I ask because I'm wondering if I should care about docker in the beginning of my project which will have very few concurrent users/requests and would run fine on a single machine. EDIT: Thank you to all the kind answers!

pknopf 8y ago
The Docker CLI will be around for a long time. This post is just FUD. There isn't another runtime that is as easy to use as Docker.
- macintux 8y ago
  The post was primarily about the company. The CLI can be around for decades, but that doesn't necessarily mean Docker the company can profit from it.
- cpitman 8y ago
  Part of the article calls out how the alternatives (like CRI-O) are shipping docker compatible CLIs, so that users can keep going `docker build` but with a completely different runtime.
  - raesene9 8y ago
    CRI-O isn't comparable to Docker for developers, it's a replacement for Docker when used as part of a Kubernetes cluster. The thing is that whilst various operations are shipping bits of the functionality that Docker provides in various different tools, for developers working with containers none of them (that I've seen) have an easy to use, cross-platform setup.
geezerjay 8y ago
Docker is immensely useful when starting projects that use web services because it lets developer download and run instances of any service on demand with a single CLI command, and lets any teammember do the same with your work. Then with docker-compose you are able to instantiate custom deployments of your projects, including dbms and gateways and messa buses and IAM services, with a single command (docker-compose up). So yes, it's very useful. However, the point of the article is that Docker is no longer the only option, and although right now it's the default go-to container tool, there is nothing but inertia keeping the world using Docker.

pknopf 8y ago

The article mentions Kubernetes using containerd and the OCI is the future, but also fails to mention that containerd is developed by Docker, which supports OCI, which largely supported by the Docker company. As of the latest versions of Docker, the dockerd is now using containerd under the hood. I'm not sure how the Docker CLI will exactly die. The posts seem to focus on the CLI only, and even calls out that "the viability of the company Docker is outside the scope of the post", but it failed mention my previous points.

scaryclam 8y ago
Containerd is a project within the Cloud Native Computing Foundation, which in turn is part of the Linux Foundation. Docker haven't been directly involved since 2015, and even then, it's arguable that they've never been (you may be thinking of runc though, which was donated in 2015). It's true that Docker uses containerd under to hood, but that's actually part of what the author is arguing. Docker as a technology is a wrapper platform around core industry technologies that they neither own or control. That means they have to compete as a tooling company, and they have already lost ground there. The more things like Kubernetes and podman join the market, the less required Docker becomes, which means they're going to be more and more at risk of failing. https://en.wikipedia.org/wiki/Linux_Foundation#Containerd https://en.wikipedia.org/wiki/Linux_Foundation#Containerd edit: added link for reference
- pknopf 8y ago
  > Docker haven't been directly involved since 2015, and even then, it's arguable that they've never been A large majority of even the recent commits to containerd are made by Docker employees. https://github.com/containerd/containerd/commits/master https://github.com/containerd/containerd/commits/master > It's true that Docker uses containerd under to hood, but that's actually part of what the author is arguing. Docker as a technology is a wrapper platform around core industry technologies that they neither own or control. I cede your point, but it's irrelevant and isn't want the author implying (even directly). From the article: "I do not think there is any reason for us to user docker any more and therefore Docker as a technology and as a company will slowly vanish." The end users do not care how cgroups are setup or mount points are built. The guts may be standardized, but the docker toolchain (Dockerfile, docker-compose, docker run) will continue to exist. The "runtime" is irrelevant and there just isn't a competitor in the "tool chain" arena. Docker Swarm is the only thing that will vanish. > The more things like Kubernetes and podman join the market, the less required Docker becomes, which means they're going to be more and more at risk of failing. Kubernetes is an entirely different use-case. Nobody is arguing Docker Swarm will beat it. You could say the Docker CLI isn't required with the advent of other tools, but those are incredibly big shoes to fill. Think of all that entails (Dockerfile, docker-compose, the CLI, cross-platform(-ish) support for Windows/OSX). Also, competition leads to better tooling. Did anyone ever say "Unix isn't required any more, because with have Linux"? The tooling of the Docker CLI is in a very good spot as-is. The guts are being opened, which I think would relieve the pressure some may feel to jump from Docker.

nathan_f77 8y ago

Are there any container filesystems that support multiple inheritance, and create diff layers? It would be really nice if I could build a few different things independently, and then merge the final images together. Also if I could only include files that have changed in a new layer, and ignore duplicate files (even if the file was touched, or the timestamp has changed.) Those are my biggest pain points with Docker at the moment. I have a complex build script that uses multi-stage builds and rsync to achieve this [1], but it's still a bit slow and inefficient. Would be nice if something supported this out of the box. I've worked on a lot of projects where people just reinstall (and recompile) their entire list of dependencies (Ruby gems or NPM packages), and you have to jump through hoops to set up a caching layer, or maybe install them into a volume as a run-time step, instead of at build time. There should be a much better native solution for this, instead of needing to invent your own thing or read random blog posts. [1] https://formapi.io/blog/posts/fast-docker-builds-for-rails-and-webpack/ https://formapi.io/blog/posts/fast-docker-builds-for-rails-a...

narrowband 8y ago
That sounds somewhat like my current project [0]. Currently it's in the prototyping phase, so it won't be released for a while, but it's coming along nicely. Your use case is one I've been planning to support all along, although I think about it a bit differently - in terms of composition of (partial) images rather than multiple inheritance. [0]: Dev blog: https://www.narrowband.org.uk/ https://www.narrowband.org.uk/
Nullabillity 8y ago
Nix[0] does this, sort of. It doesn't merge everything into one tree at runtime, but instead builds every package to a unique path, which gets embedded into downstream dependees. It assembles the dependency tree into a DAG, and uses this to automatically parallelize builds (where safe). Builds automatically run in ephemeral containers, to ensure that all dependencies are accounted for. There are also importers for many languages, and an exporter for Docker images (where each Nix package becomes one Docker layer, up until a limit that you specify). [0]: https://nixos.org/nix/ https://nixos.org/nix/
cpuguy83 8y ago

zmmmmm 8y ago

> When people understand that they can easily make the choice to swap out the container runtime, and the knowledge is out there and easily and readily available, I do not think there is any reason for us to user docker any more and therefore Docker as a technology and as a company will slowly vanish How about MySQL as a counter argument? It's always been feature-weak compared to PostgresQL, with a less business friendly license and now owned by one of the most despised software companies by technologists. But it's probably still the default relational database people pick up. Habit, defaults and massive installed base can go a long, long way.

kikoreis 8y ago
You are right, but it is hard to see how for profit Docker Inc benefits from that. MySQL had a business model that was similarly challenging, which lead to where it is today.
- user5994461 8y ago
  MySQL has a strong ecosystem model and it's a pain to switch databases. Young developers used to get a LAMP stack, Linux Apache MySql Php and that comes with MySQL. There are many products, one could say even languages, that require MySQL. The database is the hardest component to switch and even if the company were to disappear today, it would take decades to migrate off. Docker has none of this. It only happened a few years ago, it will be gone as quickly. It doesn't even have a strong brand name, people want kubernetes not docker, docker is merely a dependency that can be replaced.
  - kikoreis 8y ago
    Yeah, I agree. MySQL was in a more robust position, and even then the outcome was disappointing. Open source business is tough.
imhoguy 8y ago
Container engine is just a wrapper around couple of Linux APIs mainly cgroups & namespaces & iptables/BPF - there is most of hard work done. A good example how trivially it can be implemented is this: https://news.ycombinator.com/item?id=9925896 https://news.ycombinator.com/item?id=9925896 Now, implementing DBMS with even basic SQL query language, is not a trivial job.

McDonaldized 8y ago

In this thread, we resist the reduction of complexity, to the effect that job security is maintained, such that our careers are not commoditized by McDonaldsization.

codegaucho 8y ago

Who is providing a container registry that can replace the offering from Docker (the company)? That seems to be the big contribution of Docker the company these days: a huge library of container images.

itomato 8y ago
..that have stagnated and are now riddled with vulnerable components.
- zapita 8y ago
  Really? The official images have been quite solid and up-to-date in my experience. Has that changed since last year?

sheeshkebab 8y ago

Docker should just merge with Npmjs. Then they might get big enough to get bought up by Microsoft, Oracle or IBM (which I think is their end game anyway).

rcdmd 8y ago

Nope. Docker's value isn't just its software. It's the support built around it, tutorials, familiarity and common usage, Dockerfiles, huge Docker Hub, existing setups relying on it and so on. Articles like this tend to overlook the value of entrenched technology that works well enough.

user5994461 8y ago
Funny enough. Kubernetes ignores pretty much all of that in favor of its own, making experiences in running Docker alone mostly worthless.

rleigh 8y ago

I do like the fact that docker now works for non-Linux cases, like Docker on Windows with Windows containers. Would be nice if they would also support MacOS containers, FreeBSD etc. That would certainly entrench themselves as a "universal" container technology.

wwarner 8y ago

I basically agree with the technological argument made in the post. Orchestration plays the role of OS, where resources are defined, managed and protected. Containers are something analagous to device drivers, presenting the underlying resource as narrowly and efficiently as possible. But that's the life I expect, not the one I live today. In the present day I'm much more reliant on docker than on kubernetes, and I cannot live without being able to freely mix and match go, python, or Java , really old and really new, in any host configuration I want.

languagehacker 8y ago

It's not clear to me that the author has a solid understanding of how Docker makes it money. You don't make money just by giving away software, and you also don't make money by providing support software for no one uses. Docker has been pretty smart to build a well-known brand around supporting a specific set of technologies -- some theirs, and some not. When it became clear they were unable to own every part of the container ecosystem, they made smart decisions around supporting k8s and engaging the open container standard. Docker's got lots of runway providing enterprise support contracts, so I'm not worried about them. I think the author's also not noticing that orchestration was really a bit of a stumbling block that would eventually be removed. Sure, you've still got to use k8s in self-hosted, GCP, and Azure, but those of us on AWS have the option to use ECS with Fargate and have many of the core features of something like Kubernetes fully managed. So anyway, this post is a bit dramatic, and maybe has a few blinders on.

tobbyb 8y ago

What is wrong with Docker? This does not address any technical or other shortcoming and only seeks to replace one set of over engineered tools with another with the exact same problems. [1] The is yet more of the ecosystem continuing to push over engineered tooling and 'winners' breathlessly without basic technical scrutiny that leaves end users dealing with needless complexity and debt. Containers can be useful as a lightweight, efficient alternative to VMs and those who want containers untouched by questionable ideas should try the LXC project on which all this was based. Any additional layer on top of this be it non standard OS environment or layers should meet technical scrutiny for end user benefits and most users will be surprised by the results. [1] https://www.flockport.com/guides/say-yes-to-containers https://www.flockport.com/guides/say-yes-to-containers

Aeolun 8y ago

Yeah, no. Docker is still here and is finally being embraced by larger enterprises (if they haven’t already). I don’t see it being switched out for any unproven technology any time soon.

EliRivers 8y ago

Docker was the company that changed the world I think I've seen one person use docker once, back in about 2013, to create and freeze a very particular Latex setup. Everybody sees a tiny slice of the world, but to each individual, that slice looks like all of it.

itomato 8y ago
How many people have you seen printing money?
- EliRivers 8y ago
  Yes, I need to speak more simply, for the kind of HN commenter who revels in minutiae and takes pleasure in ignoring meaning to pursue literality and arguments about arguing. Unless you want to argue that the invention of money and the invention of docker have had comparable effect on the world? Go on, now push your hypothetical spectacles up along the bridge of your nose and say "Ah, ah, I said 'printing' of money!"

windexh8er 8y ago

The death of Docker could potentially happen, but not for the reasons the author lays out. The last argument in the article is interesting. The author implies because RHEL dropped Docker - then game over. But if we want to analyze this it isn't because Docker lost a technology battle. It's because RHEL is protecting their ecosystem. The article is correct in making the case there is choice. However the author doesn't put two and two together with regard to RedHat. Just because you can alias podman with docker doesn't really mean anything. Someone seems to have dipped into the non-reality of Docker-is-a-bad-word, by author Dan Walsh of RedHat. Also keep in mind containerd was contributed by Docker and is the graduated runtime in CNCF. You definitely don't need Docker to run containers. But it's easy to use Docker to run and build. And Docker is still a one line installation on all Linux platforms (https://get.docker.com https://get.docker.com) Next is Docker Enterprise. Can they sell it? This is where Docker is making mistake after mistake IMO. Docker does have a leg up in Windows. But does it matter? Today Swarm is your only orchestration option and while I understand k8s support is coming it still remains to be seen if GMSA is included in the first release (doubtful). If you're a Windows developer and you're deep in the Microsoft ecosystem, you won't be able to productively use Windows Server and k8s this year is my guess given the timelines. Regardless, Docker has done a poor job capitalizing on Windows. Maybe it's that people just don't need it as much as Docker would have you to believe? Or maybe it's too jarring of a workflow change. Regardless, it isn't working. Next is the products you get for the money: Docker Universal Control Plane (UCP), Docker Trusted Registry (DTR) and Docker Enterprise Engine (EE). They're all OK. But the sell is, again, tough. UCP is basically a dashboard for centralizing RBAC for Swarm and UCP in the enterprise, and don't get me wrong - the enterprise needs this. But UCP feels lacking. The UI is distracting and has a lot of oddities. Managing it is a decent amount of work. It's just OK. Also Docker UCP still doesn't support k8s PaaS while competitors do. Remember that Docker hired Kal De away from VMW as CTO. In his time at Docker not much has changed externally, but Docker needs to move faster. Much faster. DTR is interesting because everyone who's doing containers in the enterprise needs an image repository with, again, those enterprise requirements. And DTR delivers this, but Docker doesn't want to sell you DTR only. You can't buy DTR by itself like it's competitors. Docker wants you to only use all of their bits and it's dumb because Docker claims choice as a core pillar then tries to lock you into UCP+DTR+EE. Oh I see Steve... Choice as in what DOCKER defines for me as choice. Choice of bare metal or hypervisor, but not how I manage containers and orchestration? Back to DTR: it's decent, but again there are other choice and a lot of them are better standalone offerings. Finally EE. There are about three reasons you really need EE. The first is enterprise support and long term releases. The second is runtime enforcement of signed images at the engine level. The third is oddities like FIPS support. But that's it. And, again, Docker doesn't want you to buy just Engine. They want to sell you the 'platform'. At the end of the day Docker has good products. They're not exceptional when taken into context of other enterprise software. They're just OK. Docker doesn't realize this yet from what I've gathered. They have recently changed pricing to very VMW-esque CPU count pricing. And Docker doesn't have the market capital to make that leap, unfortunately. At the end of the day my opinion is that Docker is marred by Docker. Not by the competitive landscape. Yes, that contributes to Docker overall but Docker doesn't seem to make sure they have the best product above everything else. Docker's CEO, Steve Singh, is the wrong guy for the job. He is constantly stating cash flow positive by end of this fiscal year yet doesn't seem to care about how good or bad the product actually is or why people wouldn't buy Docker over something else. So yeah... Docker has done great things. Those great things are all of the contributions Docker has made to the community and continues to do so. But Docker on the enterprise side feels weak, lackluster and very confused. Docker is marred by Docker management and executive ranks from within. I'll give them 2 years make or break and I think, as it stands today it's a coin flip. The acquisition of RedHat by IBM was a good thing for Docker, but may be the nail in the coffin for RHEL long term. If Docker does flounder any longer look for them to be acquired by Microsoft. And then... Docker will be set to sail off into the ether.

nisa 8y ago

I'm using Swarm on a small cluster (3-5) machines. Is there any reliable Kubernetes alternative for that? Portainer as Swarm UI was buggy for me - a usable and stable UI would be nice, but I'm not sure if I should do the full Kubernetes dance :/ Easy to debug and lightweight would be also great. I didn't really found something good.

tpetry 8y ago
Almost all non kubernetes docker solution seem to be no longer maintained. But nomad is alive and has interesting concepts.
ofrzeta 8y ago
It's not like Kubernetes has a better UI. You could take a look at OpenShift. It's a Kubernetes based Open Source distro my Red Hat and it includes a quite nice UI, both for users and admins.
GordonS 8y ago
I'd be really interested to know more about your setup and processes if you're running Swarm in production? For example, how do you handle rolling updates?
- nisa 8y ago
  we are not a SaaS company, we just run some simple nodejs based services on swarm and my goal is to use swarm as a testing hub for docker - mostly the ci should push something there for the devs. So uptime does not matter, however swarm crashed badly a few times on me and at the moment everything important is well configured outside using your typical LTS linux distribution and I'm hesitant to move our basic services to it...basically 9-5 it has to work, I can just run apt-get update && reboot earlier or later - really not sure if I should move all the stuff into swarm / k8s - also because bus factor would be one and there is some experience with the old linux way. For everything that resembles a microservice/service -> Docker, everything else (ldap, mail) -> oldschool. So far so good. I'm looking at k3s or minikube with rancher as ui - maybe that's better, or we just ignore the hype and run docker-compose.yml files by hand but that's also pretty shitty.

auslander 8y ago

> .. All the cool kids on the block are no longer using docker as the underlying runtime. Cool kids are not using containers at all, they use cloud VMs and autoscaling :) Simple is not easy (tm)

hartator 8y ago

The main thing is Docker has been used as a way to distribute binaries with all dependencies builtins. Bypassing all OS packaging systems. It’s a hack on top of our broken packaging models. That does work but it is extremly fat and not very elegant.

MindTooth 8y ago

Based on this, I've tried most of today to make minikube work on macOS. But as I'm using DNSCrypt-Proxy I had major issues making it work without manual steps. So far, the Docker for Mac is a solution that just works. If someone have some experience, I'll gladly want to know how you make it work flawless.

btbuildem 8y ago

Since the author doesn't name any of the alternatives: https://containerjournal.com/2019/01/22/5-container-alternatives-to-docker/ https://containerjournal.com/2019/01/22/5-container-alternat...

ofrzeta 8y ago

I don't get why not more people are using Swarm. It's simple and it get the job done for many people who don't need a full Kubernetes setup. Also, for instance, it encrypts secrets, opposed to Kubernetes which only does Base64 encoding of secrets. I do understand the market dynamic but still there are niches for other simpler products.

dankohn1 8y ago
Kubernetes supports encryption at rest of secrets: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ https://kubernetes.io/docs/tasks/administer-cluster/encrypt-... They're encrypted in transit via mTLS.

CWuestefeld 8y ago

All 3 big cloud providers, now have a managed Kubernetes solution that they offer to their customers (and as a result will eventually sunset their own home-made solutions that they built over the years - because there can be only one). I haven't heard anything about this from AWS. Certainly they've introduced EKS, but I haven't heard anything about setting their ECS orchestration out to pasture. Does anybody have information about this?

peterwwillis 8y ago

This is sad, because what made Docker useful was a full feature set. We could already build chroot environments. We could already keep remote images. We could already set up app-specific networks. Having the tools wasn't what we needed: it was the confluence of all the features. If the alternative to Docker becomes learning 50 new tools, we'll have failed as an industry, and shouldn't call ourselves engineers. You don't replace a car with a wheel barrow-lawn mower-hand held radio-portable fan. This obsession with churning out a new tool every year has to stop.

miguelmota 8y ago

Yea there are alternative Docker runtimes and Kubernetes won the orchestration war but Docker images are here to stay. As far as I know there aren’t better alternatives for Docker images and even Kubernetes uses Docker images. Docker as company currently has a Red Hat-like business model and that’s certainly hard to sustain so agree on that front.

Rafuino 8y ago

Are Kata and Clear containers actually a Docker replacement?

raesene2 8y ago
Not really. They can be used to replace one element of the docker stack, runc

ilaksh 8y ago

What do you replace Docker Hub with?

williesleg 8y ago

Just another FUD hit piece.

thruhiker 8y ago

I've always disliked articles that use this tone. It's meant to be informal, but comes off as lazy and spoken in muted tones as if the author were in a pub; Docker sitting in a booth a few meters away blithely sipping on a pint of bitter. The substance isn't much more enlightening than typical bar banter either. Docker played a pivotal role in creating our modern understanding of containers and we should be thankful for that. I don't understand the value this article provided beyond pointing out a few container runtimes I hadn't heard of.

redsavagefiero 8y ago

Still using LXC where it makes sense and never felt the call of Docker...or Kubernetes or any of this developer popularized opaque tooling over sophisticated meddling with my systems.