16 ms·

Docker's Second Death

302 points by alexellisuk 6y ago

arpa 6y ago
What's the way to directly interface with containerd?
- dijit 6y ago
  How do you mean? The CLI? That’s `ctr`: https://github.com/projectatomic/containerd/blob/master/docs/cli.md https://github.com/projectatomic/containerd/blob/master/docs...
  - jcelerier 6y ago
    is it able to pull a random ubuntu or fedora image ?
    - AsyncAwait 6y ago
      Yes. The image standard for containers is called OCI and there are several ways to use them outside of Docker.
      - jcelerier 6y ago
        but, where does it pull them from ? who's hosting the images ?
        jsmith45 6y ago
        They default to docker compatibility, so if you specify 'busybox' it will pull your default registry, which defaults to dockerhub. If you specify 'k8s.gcr.io/etcd-amd64', then it will try to pull from google cloud registry. You can redirect such urls to a different registry if you prefer, by using the containerd mirrors configuration.
- deleted 6y ago
  [deleted]
- wmf 6y ago
  Check out https://github.com/AkihiroSuda/nerdctl https://github.com/AkihiroSuda/nerdctl
baggy_trough 6y ago
I enjoy using systemd's nspawn containers.
waynesonfire 6y ago
thanks for all the fish!
lima 6y ago
So, what's the better business model for a low-level piece of infrastructure like Docker?
- cercatrova 6y ago
  Really, there is none. After reading through so many of these types of threads, I'm convinced there is no sustainable business model for open source infrastructure. The best bet would be to build proprietary paid services on top of the open source infrastructure. See Laravel's projects.
  - cpitman 6y ago
    This seems at odds with the multiple open source kubernetes distributions on the market. The problem isn't that Docker is open source infrastructure, the issue was that it remained too low-level as a container daemon, didn't manage to build a large community around swarm, and then were really late to embrace kubernetes. There easily could have been an alternate history where Docker Inc was the first one out of the gate with an enterprise kubernetes distribution, been a positive part of the community, and been a success.
  - pbiggar 6y ago
    Fully agree. I'm going to keep your post in mind when I write about the business model of darklang.
    - cercatrova 6y ago
      Hopefully it goes well, I heard about the downsizing and the OCaml to F# transition.
      - pbiggar 6y ago
        Thanks!
  - zokier 6y ago
    > I'm convinced there is no sustainable business model for open source infrastructure From my personal point of view, the most sustainable way of funding development of free software is through businesses that utilize that software, but whose main business is not that software. The value proposition for the business to open source their software is mainly in getting improvements from outside, and to ensure better integration with other free software. But the main reason to build software should be selfish in the sense that you can directly use it yourself, and not the idea that you could somehow sell the software in some way or form.
andrewguenther 6y ago
Docker Inc's antagonistic attitude towards Red Hat and personal attacks on their engineers was the beginning of the end for them. The people who really headlined those attacks are now gone, but the damage was done. Docker made it clear from the beginning they had no desire to be part of a community and now the community is leaving them behind. Good riddance.
- axaxs 6y ago
  Any good source/summary of the above? I guess I'm out of the loop, but attacking a company as trusted as Red Hat seems a bad idea.
  - andrewguenther 6y ago
    It's difficult to dig up old drama when "Docker" is in your Google search, but this article gives a peek: https://lwn.net/Articles/676831/ https://lwn.net/Articles/676831/
    - zapita 6y ago
      Every time there’s drama about Docker being mean, it’s almost always a Red Hat employee behind it... Like this article, and the OP blog post. Maybe just a coincidence.
      - X-Istence 6y ago
        The op has posted in this thread that they are no longer at Red Hat... so your comment is wrong.
        zapita 6y ago
        I’m talking about the lwn article. The post is by an ex-RH employee and clearly influenced by their experience at RH.
        6y ago
skrebbel 6y ago
I feel like I'm missing some key insight here. To me, the tl;dr of this post is: Kubernetes removed the need for Docker just to run container images in a k8s cluster, ergo, Docker is dead. But Kubernetes is super complicated. The author seems to assume that everybody wants to run everything in Kubernetes, but if I want to run some backend on some server (or maybe on a few servers), then it feels like extreme overkill. Now, I'm no guru in this field at all. In fact, one thing I always liked about Docker is it made you feel able to atomically deploy software without having to become an expert at anything first. But what's the current "don't have to be an expert" way to ship software if Docker is, supposedly, dead? Do we all have to learn Kubernetes? I've never used Swarm but I've been told that one thing it had going for this is that it allowed you to do smallish setups pretty easily. If that's true, then I'm sad it lost the popularity war.
- sz4kerto 6y ago
  Swarm was great. It takes literally 30 seconds to put together a cluster with a few nodes. (1 command per host.) The problem was that Docker Inc. tried to push people towards Docker EE (that had all kinds of extra functionality above pure Swarm), but that was super buggy.
- goatinaboat 6y ago
  But Kubernetes is super complicated. It can be, but running minikube or k3s on your laptop is trivial, and what you do with them transfers very easily to real Kubernetes.
  - skrebbel 6y ago
    Will that allow me to ship software to servers (not enormous clusters, I mean like a couple of VMs somewhere) without having to first become a Kubernetes expert? I mean, that was one of the key Docker promises, and they delivered to quite an extent.
    - github_drop_ice 6y ago
      You want helm or one of the many, many tools built on top of kubernetes to ease the deployment of applications. All of the same complexity of deploying services was there with docker, you were just insulated and hidden from it by some of its opinions. Whether you want to or not, if you want to manage costs and performance of your app you're going to need to learn (or pay people who have learned) about how to deploy and manage apps in production at scale.
hmottestad 6y ago
I enjoyed the following: > Though it [Docker] does live on strongly within CI/CD ecosystems and, ostensibly, the inner loop of development thanks to the de facto standard Dockerfile. Docker will still live on for both Windows and Mac developers. As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive. Docker is still the simplest way to install Elasticsearch, to make sure everyone on your team is using the same Java version, or run up a production equivalent environment on your laptop. Regardless of if you are on Linux, Mac or Windows. I still love Docker and hope they end up finding a good business model so they can continue to live on.
- grogenaut 6y ago
  Back in 2013 before I took a job at amazon but after working with a game dev for playstation I had 2 months off, playing with docker I realized how good it's be for crap like chroot jail dev or multi-project dev env isolation. There were big blockers for it being used this way then. I did some chatting with the docker team and we did push things a little in that direction. But the vision was still about running in prod. To their credit the docker folks I talked with did listen and respond and move the needle (obviously) on it being a local dev tool, so I cheer them for that. I use it all the time in my windows box for dev. Tho I do try and keep my software able to run on any os.
  - politelemon 6y ago
    Their collaboration work on integration with WSL 1 and 2 has been fantastic.
    - deeringc 6y ago
      What's your workflow with WSL2 and docker for Windows?
      - eropple 6y ago
        Not that poster, but I use Fedora in WSL2 and the Docker for Windows integration and things (and by things I mostly mean `docker-compose`) just...work. They have some k8s stuff I've never looked at, too.
dave_4_bagels 6y ago
So what should we use for a local "kubernetes" stand in on mac os?
- deleted 6y ago
  [deleted]
- github_drop_ice 6y ago
  minikube. It works with every hypervisor (or even old docker desktop) and spins up a linux VM to run all the kubernetes services, your containers, etc. The CLI is dead simple to learn (minikube start and you're done) and the tool is endorsed, used and maintained by the official kubernetes team.
- WJW 6y ago
  There's always minikube/k3s, but I think the article overblows the death of Docker a bit. Docker no longer being required in k8s is going to hurt its potential in "prod" for sure, but the `docker run` style commands for running a db locally will work for a long long time.
- AsyncAwait 6y ago
  HashiCorp's Nomad is decent, but I don't think Docker competes with k8s at this point.
- raesene9 6y ago
  This article seems to be focusing on using Docker on production servers, rather than as a Developer tool, which is where Docker the company are focused now. As a developer tool I'm not aware of another option which has a similar setup. You can , of course, manually spin up VMs and install kind/minikube/k3s on them, but that may be more work than you want.
black3r 6y ago
Even though Kubernetes won't use Docker inside anymore.., Docker is still a very good piece of software for easily running Linux images on Windows and Mac. Dockerfile is still the easiest way to build images (even though now there are alternatives to docker build such as buildah). docker-compose is still a very simple way of running containers locally if you don't need kubernetes (e.g. on my raspberrypi for running homeassistant, transmission and plex)... but yeah.., Docker Inc. overestimated their importance and got what they deserve = Open Source tools wanting to distance from them.
- pm90 6y ago
  After they released local kubernetes support for the docker mac client, I've stopped using docker swarm completely. Although to be fair, I didn't use it all that frequently anyways. If your language runtime supports testcontainers (https://www.testcontainers.org/ https://www.testcontainers.org/) I would strongly suggest using that over docker compose. Docker compose is so lacking in features that I would just write bash scripts to setup/tear down container dependencies. But testcontainer removes the need to write bash scripts and provides some basic orchestration features that make it an absolute breeze to use.
  - viraptor 6y ago
    What features do you find missing in compose?
    - pm90 6y ago
      https://docs.docker.com/compose/startup-order/ https://docs.docker.com/compose/startup-order/ I see that they now recommend some workarounds to fix this issue, where I want to ensure that dependencies are running before spinning up my app. Usually, this is in the context of integration tests. The inability to support this "natively" makes the integration tests somewhat flaky and unreliable.
      - nikisweeting 6y ago
papito 6y ago
Kubernetes is and will be a solution to a problem most organizations don't have.
- loriverkutya 6y ago
  Like scaling and fault tolerance? :)
  - viraptor 6y ago
    You can do scaling and fault tolerance without a mesh networking approach. We've been doing it for a long time, even including containers as app delivery.
  - dijit 6y ago
    Kubernetes adds some nice stuff but “scaling” and “fault tolerance” can be achieved very easily without it. Kubernetes is great because it’s a very standard way to interact with computers. Doesn’t matter really if it’s google cloud, on prem, AWS or whatever, it is the same. The idea being that it abstracts away a lot of the toil work of ops, with the very obvious caveat that you don’t know what the sausage factory is doing. I’m pretty kubernetes neutral, some of the concepts are great and deserve replication. (Kube-dns + etcd!, sidecars, scheduling to a cluster) Some are pitfalls that might cost a lot of people a lot of time in the future. (Networking and storage abstractions being prominent examples) But as with everything, it’s pros and cons, the complexity being a pretty large con in my personal opinion. I say this as a person who is currently converting a lot of stuff to kubernetes because it solves some particular problems we have really well.
  - papito 6y ago
    Care and feeding of a production Kubernetes cluster requires constant care, feeding, and maintenance of expertise that would cost any company hundreds of thousands of dollars a year. Have we really arrived at a point where a good old autoscaling group with a few servers and a replicated database is just not good for anything?
deleted 6y ago
[deleted]
mrfusion 6y ago
What’s the TLDR?
zapita 6y ago
I don’t understand all the drama. I remember when everyone complained that docker was too monolithic and controlled by one company. In response they spun out a spec (OCI), an implementation of that spec (runc), then their entire freaking runtime (containerd). They focused on making Docker more of a developer tool with Docker for Mac and Windows. Kubernetes continues to use OCI, runc and containerd - so basically the parts of Docker the kubernetes community asked for. Yet here we are commenting on their demise as a business, blaming it on their “not being nice” and “not listening to their community”. It’s bullshit. We should be discussing how the longstanding tension over the role of Docker in the Kubernetes was finally resolved, in large parts through the successful efforts of the oci, runc and containerd projects which Docker started and shepherded to mass adoption. Let’s take a step back and look at who is pushing this narrative about Docker, and how they benefit. I can’t help but notice whenever this drama pops up, a Red Hat employee is involved. Maybe it’s time for Red Hat to give up on old grudges and give credit where credit is due? Just a thought. Docker may have failed as a business but it’s ridiculous to blame it on their lack of openness when their number one problem was being too open and trying too hard to get everyone to love them. Basically the opposite of what this blog post claims.
- tariqislam_ 6y ago
  Hey there. Author of the article here. I'm no longer a Red Hatter and my words are strictly my own. I don't intend to push a narrative, rather my intent is to communicate what I experienced with Docker in an enterprise setting across time. A lot of this also comes from my time outside of Red Hat as well.
  - tariqislam_ 6y ago
    I'll also comment specifically on your remark: I never mentioned Docker's behavior in the community, good or bad. The story of the Summit shirts was to illustrate their entry as a competitor and how that changed the narrative. I give Docker immense credit for what they did, and I state as much toward the end of my post.
- pm90 6y ago
  I agree with you. Fact: Docker is insanely popular with devs but Docker Inc. is struggling as a company. Devs have invested a lot on the platform and entire production systems and deployment pipelines use it. k8s announces "we're no longer supporting docker shim!" and what most devs heard is "k8s is moving off from docker (which we know has been struggling for a while)! Fuuuuuccckkkk what do we need to do??" and panicked. This is the source of the drama, and we're going to see many "takes" on it. Its just the way the blogging ecosystem works.
raesene9 6y ago
To me this article conflates the removal of a piece of legacy hard-coding (dockershim) with the overall death of Docker. That removal doesn't mean that Docker won't be used as part of Kubernetes clusters any more, Docker/Mirantis have committed to creating a CRI plugin for Docker. But realistically Docker the product is primarily a developer tool and I don't see that going away. Docker for Windows/Mac is the easiest way to use containers, without having (mostly) to worry about low-level implementation details. Whether that can be translated to a successful business model, is another question :)
- tariqislam_ 6y ago
  Author here. Thanks for your comment! I struggled with this as well. I agree that I might be conflating things a bit, but I did try to contextualize the slow but gradual move away from all things docker with the fate of the company, starting with the platform wars and resulting in the runtime deprecation. I think a lot of what happened came about because Docker took on Kubernetes with Swarm and lost.
  - nrvn 6y ago
    But take a look at this from a different angle. Yes, from the business perspective Docker, inc. seems to be failing badly. But from the engineering perspective they did a tremendous job splitting the monolith to separate components. Containerd was once part of Docker daemon and then abstracted away to an independent entity. And we all hugely benefit from this split. Now, the next big thing is happening - buildkit. It is already possible to build containers using buildkit without docker. There is even a plugin for kubectl for convenience. Docker is tearing itself apart but I see only good things happening around it. P.S. It has been possible to use containerd directly as CRI for Kubernetes since v1.10 https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/ https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-...
- musicale 6y ago
  > Docker for Windows/Mac is the easiest way to use containers This is depressing. Even more depressing is that macOS still doesn't seem to have native containers. (Correct me if I'm wrong - perhaps the sandboxing system can be used as a container system including virtual network interfaces attached to process groups?) Docker images depend on Linux which means "Docker" on macOS runs in a Linux VM. Presumably docker for Windows could use WSL.
jpswade 6y ago
What do they mean by “GA”?
- nemanjaboric 6y ago
  Generally Available
- CamouflagedKiwi 6y ago
  General Availability, i.e. not in beta any more.
- Hnrobert42 6y ago
  GA means general availability. This usually means the first release containing new features, excluding beta releases. It is intended for mainstream consumption and more stable than beta. Maintenance releases come next. They fix bugs in features but generally don’t release new features. Of course, such nomenclature and how strictly it’s adhered to varies from project to project.
ffghhhg 6y ago
Give it 3-4 years until some fashionista posts about the “death” of kubernetes. Workers and their cults.
- dang 6y ago
  Could you please not create accounts to break HN's guidelines with? We're trying for something a little different than internet default here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
TuringNYC 6y ago
The article and some of the comments are a strange take. There is a place for docker. There is a place for Kubernetes. They dont have much overlap in my mind. If I want to run an elastic production system with many components, and scale each component independently, i'd use Kubernetes. ...But if I want to run a Jupyter+PyTorch stack easily w/o wasting half a day on CUDA library dependency issues, I would use Docker without Kubernetes -- because I dont want to go down the rabbithole of 1. Installing kubernetes on my laptop 2. Ingress Controller hell 2b. Ingress Controller route/path/url annotation hell to make something like Jupyter work in Kubernetes ...when I can do that in 5 minutes with docker.
- joana035 6y ago
  > 2. Ingress Controller hell > 2b. Ingress Controller route/path/url annotation hell... Sorry, but that is no hard at all and I can't imagine why you compare it to "hell". It is literally less than 20 lines to define an ingress object.
  - matsemann 6y ago
    Sometimes I've spent hours on a single config line, so having to write 20 of some unknown thing sounds scary. And it's irrelevant for what he is trying to do, which is to run something locally. With docker that's one command, vs having to set up all the other stuff as well. I've been very fan of using docker for all our dev stuff. To run something locally before it meant having correct version of lots of stuff, and possible having installed some database, configure it correctly etc. Onboarding could be days of configuring this stuff and having something fail. Now it's just download docker, run our ./setup.sh that spins up the various docker images, and one's almost good to go.
    - joana035 6y ago
      Well, looks like some fundamental knowledge is missing here, that why everything looks like "hell" or is "scary". I wonder how many lines from this "./setup.sh" could have been avoided by trying a bit harder to understand how the ingress object works. I no longer see lazyness as a good trait in programing.
nautilus12 6y ago
I just want to make absolute sure that this is NOT the case. Does this mean that docker images built with `docker build` and pushed up to dockerhub will no longer be useable in kubernetes or not?
- tariqislam_ 6y ago
  Container images built with `docker build` will absolutely be usable in Kubernetes. Docker produces OCI-compliant containers.
- deleted 6y ago
  [deleted]
solatic 6y ago
The writing for Docker for Mac is on the wall. It depends on a Linux VM, for which there is no business case to spend atrociously large amounts of resources to adapt for x86 container images to run on M1 ARM Macs. For the life of me, I don't understand why Microsoft doesn't acquire Docker. Tighten the integration between Docker for Windows and WSL2, use Docker Hub to slowly push container authors onto managed Azure container registries, and use Docker Hub as a marketing channel for Azure.
- wmf 6y ago
  Docker can run x86 images (slowly) on ARM using QEMU which is already working.
xaduha 6y ago
I guess I'll wait for a third then.
musicale 6y ago
> With all the years of bloat baked into the platform, it’s really just a matter of time before other areas to the left of the platform shed the debt of the Docker daemon Yes!
zaro 6y ago
Not a big loss, IMO. I still remeber when there was somebody on a dockercon with "I don't accept systemd patches".
- nikisweeting 6y ago
  From my understanding that was due to a long-running design philosophy clash between the systemd people thinking Docker should be using systemd primitives to manage things like unit startup/shutdown/etc., and the docker people wanting to use their in-house implementations so as not to depend on systemd (and thus rejecting PRs trying to change docker behavior to use systemd). I don't think it's fair to use that as an example of toxic behavior on either side, they each had their motivations, and a consensus needed to be reached for both projects to proceed. From what I can tell that debate seems to be old news these days and I haven't seen as much clashing between those teams. I am not a developer on either side though, this is just from the perspective of a user who follows the Github issues.
  - zaro 6y ago
    And what drove my attention to the "I don't accept systemd patches" was the need to run systemd in docker container. Which by digging a litte bit about I found it will be possible in non priviledged mode, but docker didn't want to merge it. I don't see anything philosiphical with that, it's just plain refusal to cooperate in any way with a potential compentitor. This was several years ago, now this is not an issue anymore, but it's still telling of the toxic corporate culture Docker had back then.
    - nikisweeting 6y ago
      I think the reasoning was that you shouldn't need systemd in docker because the point is for docker itself to containerize each service unit, and use something like docker-compose to manage multiple units. Personally I think that's an aggressive but valid stance because by allowing systemd in docker they'd get a ton of low quality docker images floating around where they launch multiple services within containers, which is against the "do one thing per container" philosophy. Now that docker has proliferated and the standard practices are clear and well documented, there's less of a danger allowing people to do messy things in their docker containers.
priyanshuraj 6y ago
Wonderfully written article. I like how it draws the distinction between Docker still possibly surviving in dev and ci/cd pipelines and Docker definitely being dead in production. I wonder though if something simpler than Docker would arrive for dev and ci/cd and make Docker obsolete there too.
mmcnl 6y ago
The wording seems so negative. You could also say Docker is evolving to something bigger. And that's a good thing. The simple approach to containers and the workflows that come along with them are nothing short of revolutionary if you ask me, and it will only get better.
erikbye 6y ago
RHEL and CentOS has shed this debt already.
polskibus 6y ago
Does it mean that developers working locally with containers should ditch Docker and Dockerfiles altogether? If so, what should they replace it with, esp, if all you want to deploy to prod is contained in a single docker-compose? Is switching local development to kubernetes a good idea in terms of performance, fast feedback loop, development experience (smooth flow), etc. ?
- tariqislam_ 6y ago
  Author here. In the last part of my post, I do mention that Dockerfiles are probably the one thing that will outlast everything else from Docker. There's nothing really practical to replace that artifact at this time if you ask me. There are some tools to convert your docker-compose into the k8s resource model. I'd advise against switching local development to Kubernetes. Docker found a sweet spot there, as heavyweight as it is today. I think where we'll land is Dockerfile + one of the other alternatives like kaniko, buildah, etc.
  - jacques_chester 6y ago
    > There's nothing really practical to replace that artifact at this time if you ask me. I am required by law to spruik Cloud Native Buildpacks. For most uses, I feel Dockerfiles are not necessary or desirable at this point. Disclosure: I've been around CNBs for a while for Pivotal and now VMware.
    - tariqislam_ 6y ago
      Haha, ok that's totally fair. Valid point. Thank you for bringing this up. I'd not considered them.
- zapita 6y ago
  No. Nothing will change in terms of support for Dockerfiles or support for running Docker images. The whole thing is massively overblown.
beeskneecaps 6y ago
Noob comment: is there a docker-compose and docker-compose.umm format equivalent for kubernetes or something else that has staying power? Thanks
- nikisweeting 6y ago
  Docker compose is now an open standard, just like Dockerfile, and it's wildly popular still so it's here to stay. Multiple tools besides Docker are starting to implement it (like podman). There is no need to go switching everything to Kubernetes.
deleted 6y ago
[deleted]
neves 6y ago
BTW: "goes GA" is General Availability.
zomglings 6y ago
dockershim is gone blah blah blah. Tell me, how will the great majority of developers be creating images to run on kubernetes clusters? Not buildah or whatever. They will use docker build, I wager. Docker will die eventually, yes. But not for a long time (>5 years) yet.
kristianpaul 6y ago
Docker still very simple to use, wish i could do the same with some systemd/containerd integration.
- an_human 6y ago
  Docker is an abstraction over containerd and others. Docker became what Xerox became
- IceWreck 6y ago
  If you want systemd integration, use podman. It has a docker compatible CLI and runs OCI images just like docker but unlike docker it runs daemonless and has systemd integration
lmeyerov 6y ago
That this was written by a (ex?) Red Hat employee makes a lot of sense. We burned significant time in the last 2 weeks because RHEL 8 intentionally makes it very hard to `dnf install docker-ce` (even though you are literally just installing the centos/rhel 7 package), and insteadm RH docs + staff tell IT admins who don't know better to `dnf install podman` as the only correct option and lie that is drop-in compatible. Then we get support tickets because, surprise, podman often doesn't actually replace docker due to bugs, or in areas like `docker-compose`, because it isn't even implemented. Docker's second death is very much IBM/ RHEL's anti-competitive intent. An infrastructure provider should be neutral on how they present this kind of thing, especially a company selling enterprise reliability for running software on top. The 1984-esque double speak experience has been quite souring wrt ethics of doing business with them around cloud/container-era technology and trusting them for enterprise reliability. I do find the podman ecosystem technically interesting... but due to the unethical corporate stewardship we're seeing, I'm uncomfortable seeing anyone use it.
- tariqislam_ 6y ago
  Author here. Ex Red Hat, yes. Couple of things: 1. Docker being deprecated has nothing to do with anyone's competitive intent. I believe that the Kubernetes community is optimizing away from bloat. 2. I do not espouse podman. This post was about the container runtime, which podman is most definitely not. It's been a few years since I left the company, but it's unfortunate that you've had the experience you describe.
  - lmeyerov 6y ago
    I wouldn't have written anything if dockerless was opt-in for when you wanted to experiment with dropping `dnf install docker-ce`. There's a difference between infra orgs promoting new tech as an alternative vs. blocking their competitors. Infra co's are paid to be reliable neutral providers & advisors - instead, it seems corporate greed here has folks actively breaking enterprise userland and misleading decisions makers in sensitive areas like gov, utilities, world-scale services, etc. Like I said, I found the technical goal interesting and have been following. However, working through the year+ papertrail of RH doublespeak here makes me dread having to interact with them as an active OSS dev and in my dayjob working with big businesses / govs. RHEL often has policy lock-in in these orgs, so I know it'll keep happening unless the community stops it. As is, the stewards are needlessly risking putting podman and friends into a politically contentious category similar to urbit, oracle, etc., and are costing a lot of time & $$$ from people who are already stretched thin.
justicezyx 6y ago
I am quite saddened by the article's tone: "technical debt of docker" ouch that's hurtful to Solomon and Sam... I personally always take the view that docker, by all accounts, blew off a potential once in decade chance of becoming the next VMware, because of its own arrogance and incompetence. But, I am very much disgusted by the community's misplaced hate towards docker, and the equally misguided euphemism towards the big corps, particularly Google. After all, the whole container community own it's creation to docker. One can always claim that container exits long before docker, but that's like claim there were always operating system before Unix, etc.
- chumboslice 6y ago
  I don't think technical debt is an insult. Docker is a fully-fledged platform, 90% of which is not in use in any Kubernetes cluster. It's bloat. That Swarm and everything else was baked into the platform along with the runtime makes it technical debt for those that necessarily have to support it. I don't think anyone hates docker. But there is an issue of hubris here.
  - justicezyx 6y ago
    Then it should be called technical debt of dockershim, right? I don't want to nitpicking, but the tone of the article is definitely negative. And the whole community are not showing the respect to docker as a whole and brand.

302 points by alexellisuk 6y ago

arpa 6y ago

What's the way to directly interface with containerd?

dijit 6y ago
How do you mean? The CLI? That’s `ctr`: https://github.com/projectatomic/containerd/blob/master/docs/cli.md https://github.com/projectatomic/containerd/blob/master/docs...
- jcelerier 6y ago
  is it able to pull a random ubuntu or fedora image ?
  - AsyncAwait 6y ago
    Yes. The image standard for containers is called OCI and there are several ways to use them outside of Docker.
    - jcelerier 6y ago
      but, where does it pull them from ? who's hosting the images ?
      - jsmith45 6y ago
        They default to docker compatibility, so if you specify 'busybox' it will pull your default registry, which defaults to dockerhub. If you specify 'k8s.gcr.io/etcd-amd64', then it will try to pull from google cloud registry. You can redirect such urls to a different registry if you prefer, by using the containerd mirrors configuration.
deleted 6y ago
[deleted]
wmf 6y ago
Check out https://github.com/AkihiroSuda/nerdctl https://github.com/AkihiroSuda/nerdctl

baggy_trough 6y ago

I enjoy using systemd's nspawn containers.

waynesonfire 6y ago

thanks for all the fish!

lima 6y ago

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

cercatrova 6y ago
Really, there is none. After reading through so many of these types of threads, I'm convinced there is no sustainable business model for open source infrastructure. The best bet would be to build proprietary paid services on top of the open source infrastructure. See Laravel's projects.
- cpitman 6y ago
  This seems at odds with the multiple open source kubernetes distributions on the market. The problem isn't that Docker is open source infrastructure, the issue was that it remained too low-level as a container daemon, didn't manage to build a large community around swarm, and then were really late to embrace kubernetes. There easily could have been an alternate history where Docker Inc was the first one out of the gate with an enterprise kubernetes distribution, been a positive part of the community, and been a success.
- pbiggar 6y ago
  Fully agree. I'm going to keep your post in mind when I write about the business model of darklang.
  - cercatrova 6y ago
    Hopefully it goes well, I heard about the downsizing and the OCaml to F# transition.
    - pbiggar 6y ago
      Thanks!
- zokier 6y ago
  > I'm convinced there is no sustainable business model for open source infrastructure From my personal point of view, the most sustainable way of funding development of free software is through businesses that utilize that software, but whose main business is not that software. The value proposition for the business to open source their software is mainly in getting improvements from outside, and to ensure better integration with other free software. But the main reason to build software should be selfish in the sense that you can directly use it yourself, and not the idea that you could somehow sell the software in some way or form.

andrewguenther 6y ago

Docker Inc's antagonistic attitude towards Red Hat and personal attacks on their engineers was the beginning of the end for them. The people who really headlined those attacks are now gone, but the damage was done. Docker made it clear from the beginning they had no desire to be part of a community and now the community is leaving them behind. Good riddance.

axaxs 6y ago
Any good source/summary of the above? I guess I'm out of the loop, but attacking a company as trusted as Red Hat seems a bad idea.
- andrewguenther 6y ago
  It's difficult to dig up old drama when "Docker" is in your Google search, but this article gives a peek: https://lwn.net/Articles/676831/ https://lwn.net/Articles/676831/
  - zapita 6y ago
    Every time there’s drama about Docker being mean, it’s almost always a Red Hat employee behind it... Like this article, and the OP blog post. Maybe just a coincidence.
    - X-Istence 6y ago
      The op has posted in this thread that they are no longer at Red Hat... so your comment is wrong.
      - zapita 6y ago
        I’m talking about the lwn article. The post is by an ex-RH employee and clearly influenced by their experience at RH.
        6y ago

skrebbel 6y ago

I feel like I'm missing some key insight here. To me, the tl;dr of this post is: Kubernetes removed the need for Docker just to run container images in a k8s cluster, ergo, Docker is dead. But Kubernetes is super complicated. The author seems to assume that everybody wants to run everything in Kubernetes, but if I want to run some backend on some server (or maybe on a few servers), then it feels like extreme overkill. Now, I'm no guru in this field at all. In fact, one thing I always liked about Docker is it made you feel able to atomically deploy software without having to become an expert at anything first. But what's the current "don't have to be an expert" way to ship software if Docker is, supposedly, dead? Do we all have to learn Kubernetes? I've never used Swarm but I've been told that one thing it had going for this is that it allowed you to do smallish setups pretty easily. If that's true, then I'm sad it lost the popularity war.

sz4kerto 6y ago
Swarm was great. It takes literally 30 seconds to put together a cluster with a few nodes. (1 command per host.) The problem was that Docker Inc. tried to push people towards Docker EE (that had all kinds of extra functionality above pure Swarm), but that was super buggy.
goatinaboat 6y ago
But Kubernetes is super complicated. It can be, but running minikube or k3s on your laptop is trivial, and what you do with them transfers very easily to real Kubernetes.
- skrebbel 6y ago
  Will that allow me to ship software to servers (not enormous clusters, I mean like a couple of VMs somewhere) without having to first become a Kubernetes expert? I mean, that was one of the key Docker promises, and they delivered to quite an extent.
  - github_drop_ice 6y ago
    You want helm or one of the many, many tools built on top of kubernetes to ease the deployment of applications. All of the same complexity of deploying services was there with docker, you were just insulated and hidden from it by some of its opinions. Whether you want to or not, if you want to manage costs and performance of your app you're going to need to learn (or pay people who have learned) about how to deploy and manage apps in production at scale.

hmottestad 6y ago

I enjoyed the following: > Though it [Docker] does live on strongly within CI/CD ecosystems and, ostensibly, the inner loop of development thanks to the de facto standard Dockerfile. Docker will still live on for both Windows and Mac developers. As a platform for running production code it might be dead or dying, but as an ecosystem and a development tool it will continue to live and probably thrive. Docker is still the simplest way to install Elasticsearch, to make sure everyone on your team is using the same Java version, or run up a production equivalent environment on your laptop. Regardless of if you are on Linux, Mac or Windows. I still love Docker and hope they end up finding a good business model so they can continue to live on.

grogenaut 6y ago
Back in 2013 before I took a job at amazon but after working with a game dev for playstation I had 2 months off, playing with docker I realized how good it's be for crap like chroot jail dev or multi-project dev env isolation. There were big blockers for it being used this way then. I did some chatting with the docker team and we did push things a little in that direction. But the vision was still about running in prod. To their credit the docker folks I talked with did listen and respond and move the needle (obviously) on it being a local dev tool, so I cheer them for that. I use it all the time in my windows box for dev. Tho I do try and keep my software able to run on any os.
- politelemon 6y ago
  Their collaboration work on integration with WSL 1 and 2 has been fantastic.
  - deeringc 6y ago
    What's your workflow with WSL2 and docker for Windows?
    - eropple 6y ago
      Not that poster, but I use Fedora in WSL2 and the Docker for Windows integration and things (and by things I mostly mean `docker-compose`) just...work. They have some k8s stuff I've never looked at, too.

dave_4_bagels 6y ago

So what should we use for a local "kubernetes" stand in on mac os?

deleted 6y ago
[deleted]
github_drop_ice 6y ago
minikube. It works with every hypervisor (or even old docker desktop) and spins up a linux VM to run all the kubernetes services, your containers, etc. The CLI is dead simple to learn (minikube start and you're done) and the tool is endorsed, used and maintained by the official kubernetes team.
WJW 6y ago
There's always minikube/k3s, but I think the article overblows the death of Docker a bit. Docker no longer being required in k8s is going to hurt its potential in "prod" for sure, but the `docker run` style commands for running a db locally will work for a long long time.
AsyncAwait 6y ago
HashiCorp's Nomad is decent, but I don't think Docker competes with k8s at this point.
raesene9 6y ago
This article seems to be focusing on using Docker on production servers, rather than as a Developer tool, which is where Docker the company are focused now. As a developer tool I'm not aware of another option which has a similar setup. You can , of course, manually spin up VMs and install kind/minikube/k3s on them, but that may be more work than you want.

black3r 6y ago

Even though Kubernetes won't use Docker inside anymore.., Docker is still a very good piece of software for easily running Linux images on Windows and Mac. Dockerfile is still the easiest way to build images (even though now there are alternatives to docker build such as buildah). docker-compose is still a very simple way of running containers locally if you don't need kubernetes (e.g. on my raspberrypi for running homeassistant, transmission and plex)... but yeah.., Docker Inc. overestimated their importance and got what they deserve = Open Source tools wanting to distance from them.

pm90 6y ago
After they released local kubernetes support for the docker mac client, I've stopped using docker swarm completely. Although to be fair, I didn't use it all that frequently anyways. If your language runtime supports testcontainers (https://www.testcontainers.org/ https://www.testcontainers.org/) I would strongly suggest using that over docker compose. Docker compose is so lacking in features that I would just write bash scripts to setup/tear down container dependencies. But testcontainer removes the need to write bash scripts and provides some basic orchestration features that make it an absolute breeze to use.
- viraptor 6y ago
  What features do you find missing in compose?
  - pm90 6y ago
    https://docs.docker.com/compose/startup-order/ https://docs.docker.com/compose/startup-order/ I see that they now recommend some workarounds to fix this issue, where I want to ensure that dependencies are running before spinning up my app. Usually, this is in the context of integration tests. The inability to support this "natively" makes the integration tests somewhat flaky and unreliable.
    - nikisweeting 6y ago

papito 6y ago

Kubernetes is and will be a solution to a problem most organizations don't have.

loriverkutya 6y ago
Like scaling and fault tolerance? :)
- viraptor 6y ago
  You can do scaling and fault tolerance without a mesh networking approach. We've been doing it for a long time, even including containers as app delivery.
- dijit 6y ago
  Kubernetes adds some nice stuff but “scaling” and “fault tolerance” can be achieved very easily without it. Kubernetes is great because it’s a very standard way to interact with computers. Doesn’t matter really if it’s google cloud, on prem, AWS or whatever, it is the same. The idea being that it abstracts away a lot of the toil work of ops, with the very obvious caveat that you don’t know what the sausage factory is doing. I’m pretty kubernetes neutral, some of the concepts are great and deserve replication. (Kube-dns + etcd!, sidecars, scheduling to a cluster) Some are pitfalls that might cost a lot of people a lot of time in the future. (Networking and storage abstractions being prominent examples) But as with everything, it’s pros and cons, the complexity being a pretty large con in my personal opinion. I say this as a person who is currently converting a lot of stuff to kubernetes because it solves some particular problems we have really well.
- papito 6y ago
  Care and feeding of a production Kubernetes cluster requires constant care, feeding, and maintenance of expertise that would cost any company hundreds of thousands of dollars a year. Have we really arrived at a point where a good old autoscaling group with a few servers and a replicated database is just not good for anything?

deleted 6y ago

[deleted]

mrfusion 6y ago

What’s the TLDR?

zapita 6y ago

I don’t understand all the drama. I remember when everyone complained that docker was too monolithic and controlled by one company. In response they spun out a spec (OCI), an implementation of that spec (runc), then their entire freaking runtime (containerd). They focused on making Docker more of a developer tool with Docker for Mac and Windows. Kubernetes continues to use OCI, runc and containerd - so basically the parts of Docker the kubernetes community asked for. Yet here we are commenting on their demise as a business, blaming it on their “not being nice” and “not listening to their community”. It’s bullshit. We should be discussing how the longstanding tension over the role of Docker in the Kubernetes was finally resolved, in large parts through the successful efforts of the oci, runc and containerd projects which Docker started and shepherded to mass adoption. Let’s take a step back and look at who is pushing this narrative about Docker, and how they benefit. I can’t help but notice whenever this drama pops up, a Red Hat employee is involved. Maybe it’s time for Red Hat to give up on old grudges and give credit where credit is due? Just a thought. Docker may have failed as a business but it’s ridiculous to blame it on their lack of openness when their number one problem was being too open and trying too hard to get everyone to love them. Basically the opposite of what this blog post claims.

tariqislam_ 6y ago
Hey there. Author of the article here. I'm no longer a Red Hatter and my words are strictly my own. I don't intend to push a narrative, rather my intent is to communicate what I experienced with Docker in an enterprise setting across time. A lot of this also comes from my time outside of Red Hat as well.
- tariqislam_ 6y ago
  I'll also comment specifically on your remark: I never mentioned Docker's behavior in the community, good or bad. The story of the Summit shirts was to illustrate their entry as a competitor and how that changed the narrative. I give Docker immense credit for what they did, and I state as much toward the end of my post.
pm90 6y ago
I agree with you. Fact: Docker is insanely popular with devs but Docker Inc. is struggling as a company. Devs have invested a lot on the platform and entire production systems and deployment pipelines use it. k8s announces "we're no longer supporting docker shim!" and what most devs heard is "k8s is moving off from docker (which we know has been struggling for a while)! Fuuuuuccckkkk what do we need to do??" and panicked. This is the source of the drama, and we're going to see many "takes" on it. Its just the way the blogging ecosystem works.

raesene9 6y ago

To me this article conflates the removal of a piece of legacy hard-coding (dockershim) with the overall death of Docker. That removal doesn't mean that Docker won't be used as part of Kubernetes clusters any more, Docker/Mirantis have committed to creating a CRI plugin for Docker. But realistically Docker the product is primarily a developer tool and I don't see that going away. Docker for Windows/Mac is the easiest way to use containers, without having (mostly) to worry about low-level implementation details. Whether that can be translated to a successful business model, is another question :)

tariqislam_ 6y ago
Author here. Thanks for your comment! I struggled with this as well. I agree that I might be conflating things a bit, but I did try to contextualize the slow but gradual move away from all things docker with the fate of the company, starting with the platform wars and resulting in the runtime deprecation. I think a lot of what happened came about because Docker took on Kubernetes with Swarm and lost.
- nrvn 6y ago
  But take a look at this from a different angle. Yes, from the business perspective Docker, inc. seems to be failing badly. But from the engineering perspective they did a tremendous job splitting the monolith to separate components. Containerd was once part of Docker daemon and then abstracted away to an independent entity. And we all hugely benefit from this split. Now, the next big thing is happening - buildkit. It is already possible to build containers using buildkit without docker. There is even a plugin for kubectl for convenience. Docker is tearing itself apart but I see only good things happening around it. P.S. It has been possible to use containerd directly as CRI for Kubernetes since v1.10 https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/ https://kubernetes.io/blog/2018/05/24/kubernetes-containerd-...
musicale 6y ago
> Docker for Windows/Mac is the easiest way to use containers This is depressing. Even more depressing is that macOS still doesn't seem to have native containers. (Correct me if I'm wrong - perhaps the sandboxing system can be used as a container system including virtual network interfaces attached to process groups?) Docker images depend on Linux which means "Docker" on macOS runs in a Linux VM. Presumably docker for Windows could use WSL.

jpswade 6y ago

What do they mean by “GA”?

nemanjaboric 6y ago
Generally Available
CamouflagedKiwi 6y ago
General Availability, i.e. not in beta any more.
Hnrobert42 6y ago
GA means general availability. This usually means the first release containing new features, excluding beta releases. It is intended for mainstream consumption and more stable than beta. Maintenance releases come next. They fix bugs in features but generally don’t release new features. Of course, such nomenclature and how strictly it’s adhered to varies from project to project.

ffghhhg 6y ago

Give it 3-4 years until some fashionista posts about the “death” of kubernetes. Workers and their cults.

dang 6y ago
Could you please not create accounts to break HN's guidelines with? We're trying for something a little different than internet default here. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

TuringNYC 6y ago

The article and some of the comments are a strange take. There is a place for docker. There is a place for Kubernetes. They dont have much overlap in my mind. If I want to run an elastic production system with many components, and scale each component independently, i'd use Kubernetes. ...But if I want to run a Jupyter+PyTorch stack easily w/o wasting half a day on CUDA library dependency issues, I would use Docker without Kubernetes -- because I dont want to go down the rabbithole of 1. Installing kubernetes on my laptop 2. Ingress Controller hell 2b. Ingress Controller route/path/url annotation hell to make something like Jupyter work in Kubernetes ...when I can do that in 5 minutes with docker.

joana035 6y ago
> 2. Ingress Controller hell > 2b. Ingress Controller route/path/url annotation hell... Sorry, but that is no hard at all and I can't imagine why you compare it to "hell". It is literally less than 20 lines to define an ingress object.
- matsemann 6y ago
  Sometimes I've spent hours on a single config line, so having to write 20 of some unknown thing sounds scary. And it's irrelevant for what he is trying to do, which is to run something locally. With docker that's one command, vs having to set up all the other stuff as well. I've been very fan of using docker for all our dev stuff. To run something locally before it meant having correct version of lots of stuff, and possible having installed some database, configure it correctly etc. Onboarding could be days of configuring this stuff and having something fail. Now it's just download docker, run our ./setup.sh that spins up the various docker images, and one's almost good to go.
  - joana035 6y ago
    Well, looks like some fundamental knowledge is missing here, that why everything looks like "hell" or is "scary". I wonder how many lines from this "./setup.sh" could have been avoided by trying a bit harder to understand how the ingress object works. I no longer see lazyness as a good trait in programing.

nautilus12 6y ago

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

tariqislam_ 6y ago
Container images built with `docker build` will absolutely be usable in Kubernetes. Docker produces OCI-compliant containers.
deleted 6y ago
[deleted]

solatic 6y ago

The writing for Docker for Mac is on the wall. It depends on a Linux VM, for which there is no business case to spend atrociously large amounts of resources to adapt for x86 container images to run on M1 ARM Macs. For the life of me, I don't understand why Microsoft doesn't acquire Docker. Tighten the integration between Docker for Windows and WSL2, use Docker Hub to slowly push container authors onto managed Azure container registries, and use Docker Hub as a marketing channel for Azure.

wmf 6y ago
Docker can run x86 images (slowly) on ARM using QEMU which is already working.

xaduha 6y ago

I guess I'll wait for a third then.

musicale 6y ago

> With all the years of bloat baked into the platform, it’s really just a matter of time before other areas to the left of the platform shed the debt of the Docker daemon Yes!

zaro 6y ago

Not a big loss, IMO. I still remeber when there was somebody on a dockercon with "I don't accept systemd patches".

nikisweeting 6y ago
From my understanding that was due to a long-running design philosophy clash between the systemd people thinking Docker should be using systemd primitives to manage things like unit startup/shutdown/etc., and the docker people wanting to use their in-house implementations so as not to depend on systemd (and thus rejecting PRs trying to change docker behavior to use systemd). I don't think it's fair to use that as an example of toxic behavior on either side, they each had their motivations, and a consensus needed to be reached for both projects to proceed. From what I can tell that debate seems to be old news these days and I haven't seen as much clashing between those teams. I am not a developer on either side though, this is just from the perspective of a user who follows the Github issues.
- zaro 6y ago
  And what drove my attention to the "I don't accept systemd patches" was the need to run systemd in docker container. Which by digging a litte bit about I found it will be possible in non priviledged mode, but docker didn't want to merge it. I don't see anything philosiphical with that, it's just plain refusal to cooperate in any way with a potential compentitor. This was several years ago, now this is not an issue anymore, but it's still telling of the toxic corporate culture Docker had back then.
  - nikisweeting 6y ago
    I think the reasoning was that you shouldn't need systemd in docker because the point is for docker itself to containerize each service unit, and use something like docker-compose to manage multiple units. Personally I think that's an aggressive but valid stance because by allowing systemd in docker they'd get a ton of low quality docker images floating around where they launch multiple services within containers, which is against the "do one thing per container" philosophy. Now that docker has proliferated and the standard practices are clear and well documented, there's less of a danger allowing people to do messy things in their docker containers.

priyanshuraj 6y ago

Wonderfully written article. I like how it draws the distinction between Docker still possibly surviving in dev and ci/cd pipelines and Docker definitely being dead in production. I wonder though if something simpler than Docker would arrive for dev and ci/cd and make Docker obsolete there too.

mmcnl 6y ago

The wording seems so negative. You could also say Docker is evolving to something bigger. And that's a good thing. The simple approach to containers and the workflows that come along with them are nothing short of revolutionary if you ask me, and it will only get better.

erikbye 6y ago

RHEL and CentOS has shed this debt already.

polskibus 6y ago

Does it mean that developers working locally with containers should ditch Docker and Dockerfiles altogether? If so, what should they replace it with, esp, if all you want to deploy to prod is contained in a single docker-compose? Is switching local development to kubernetes a good idea in terms of performance, fast feedback loop, development experience (smooth flow), etc. ?

tariqislam_ 6y ago
Author here. In the last part of my post, I do mention that Dockerfiles are probably the one thing that will outlast everything else from Docker. There's nothing really practical to replace that artifact at this time if you ask me. There are some tools to convert your docker-compose into the k8s resource model. I'd advise against switching local development to Kubernetes. Docker found a sweet spot there, as heavyweight as it is today. I think where we'll land is Dockerfile + one of the other alternatives like kaniko, buildah, etc.
- jacques_chester 6y ago
  > There's nothing really practical to replace that artifact at this time if you ask me. I am required by law to spruik Cloud Native Buildpacks. For most uses, I feel Dockerfiles are not necessary or desirable at this point. Disclosure: I've been around CNBs for a while for Pivotal and now VMware.
  - tariqislam_ 6y ago
    Haha, ok that's totally fair. Valid point. Thank you for bringing this up. I'd not considered them.
zapita 6y ago
No. Nothing will change in terms of support for Dockerfiles or support for running Docker images. The whole thing is massively overblown.

beeskneecaps 6y ago

Noob comment: is there a docker-compose and docker-compose.umm format equivalent for kubernetes or something else that has staying power? Thanks

nikisweeting 6y ago
Docker compose is now an open standard, just like Dockerfile, and it's wildly popular still so it's here to stay. Multiple tools besides Docker are starting to implement it (like podman). There is no need to go switching everything to Kubernetes.

deleted 6y ago

[deleted]

neves 6y ago

BTW: "goes GA" is General Availability.

zomglings 6y ago

dockershim is gone blah blah blah. Tell me, how will the great majority of developers be creating images to run on kubernetes clusters? Not buildah or whatever. They will use docker build, I wager. Docker will die eventually, yes. But not for a long time (>5 years) yet.

kristianpaul 6y ago

Docker still very simple to use, wish i could do the same with some systemd/containerd integration.

an_human 6y ago
Docker is an abstraction over containerd and others. Docker became what Xerox became
IceWreck 6y ago
If you want systemd integration, use podman. It has a docker compatible CLI and runs OCI images just like docker but unlike docker it runs daemonless and has systemd integration

lmeyerov 6y ago

That this was written by a (ex?) Red Hat employee makes a lot of sense. We burned significant time in the last 2 weeks because RHEL 8 intentionally makes it very hard to `dnf install docker-ce` (even though you are literally just installing the centos/rhel 7 package), and insteadm RH docs + staff tell IT admins who don't know better to `dnf install podman` as the only correct option and lie that is drop-in compatible. Then we get support tickets because, surprise, podman often doesn't actually replace docker due to bugs, or in areas like `docker-compose`, because it isn't even implemented. Docker's second death is very much IBM/ RHEL's anti-competitive intent. An infrastructure provider should be neutral on how they present this kind of thing, especially a company selling enterprise reliability for running software on top. The 1984-esque double speak experience has been quite souring wrt ethics of doing business with them around cloud/container-era technology and trusting them for enterprise reliability. I do find the podman ecosystem technically interesting... but due to the unethical corporate stewardship we're seeing, I'm uncomfortable seeing anyone use it.

tariqislam_ 6y ago
Author here. Ex Red Hat, yes. Couple of things: 1. Docker being deprecated has nothing to do with anyone's competitive intent. I believe that the Kubernetes community is optimizing away from bloat. 2. I do not espouse podman. This post was about the container runtime, which podman is most definitely not. It's been a few years since I left the company, but it's unfortunate that you've had the experience you describe.
- lmeyerov 6y ago
  I wouldn't have written anything if dockerless was opt-in for when you wanted to experiment with dropping `dnf install docker-ce`. There's a difference between infra orgs promoting new tech as an alternative vs. blocking their competitors. Infra co's are paid to be reliable neutral providers & advisors - instead, it seems corporate greed here has folks actively breaking enterprise userland and misleading decisions makers in sensitive areas like gov, utilities, world-scale services, etc. Like I said, I found the technical goal interesting and have been following. However, working through the year+ papertrail of RH doublespeak here makes me dread having to interact with them as an active OSS dev and in my dayjob working with big businesses / govs. RHEL often has policy lock-in in these orgs, so I know it'll keep happening unless the community stops it. As is, the stewards are needlessly risking putting podman and friends into a politically contentious category similar to urbit, oracle, etc., and are costing a lot of time & $$$ from people who are already stretched thin.

justicezyx 6y ago

I am quite saddened by the article's tone: "technical debt of docker" ouch that's hurtful to Solomon and Sam... I personally always take the view that docker, by all accounts, blew off a potential once in decade chance of becoming the next VMware, because of its own arrogance and incompetence. But, I am very much disgusted by the community's misplaced hate towards docker, and the equally misguided euphemism towards the big corps, particularly Google. After all, the whole container community own it's creation to docker. One can always claim that container exits long before docker, but that's like claim there were always operating system before Unix, etc.

chumboslice 6y ago
I don't think technical debt is an insult. Docker is a fully-fledged platform, 90% of which is not in use in any Kubernetes cluster. It's bloat. That Swarm and everything else was baked into the platform along with the runtime makes it technical debt for those that necessarily have to support it. I don't think anyone hates docker. But there is an issue of hubris here.
- justicezyx 6y ago
  Then it should be called technical debt of dockershim, right? I don't want to nitpicking, but the tone of the article is definitely negative. And the whole community are not showing the respect to docker as a whole and brand.