11 ms·

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 tha

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).
- pilooch 8y ago
  One reason I see as an open source developer is low touch adoption and environment control. Over with build support on many Linux flavors (redhat from the past, archlinux from the ghetto :) ), use dockerized version instead. This might be my narrow corner of the world but users have driven me to dockerize much of what I do code, and my support hassle has lowered, a lot.
- zenexer 8y ago
  That sounds like a pretty solid system, but it’s not at all what the author is advocating. The author states that Docker is destined to be replaced by other containerization frameworks. The functionality differences won’t be as stark as what you’ve described, so this isn’t really a good comparison. That being said, I’d agree that netboot + tmpfs has a lot of advantages; unfortunately, it’s not always practical, especially at smaller scales. Containers are convenient and don’t require any special hardware accommodations.
- StreamBright 8y ago
  Exactly, we have POCed Docker and realised we have a solution for every aspect that it is trying to address. I found one and exactly one use case for Docker, running CI/CD workload.
- tasubotadas 8y ago
  You kinda missed the point that docker is more about packaging the applications than running them. Running apps is easy. Packaging in such a way that they could be run without hassle - hard.
  - baybal2 8y ago
    > could be run without hassle - hard. Strict versioning of every dependency - exactly the thing a packaging system solves. Specific system configuration? Also not a problem at all with netboot images.
    - Aeolun 8y ago
      Can I run netboot images anywhere easily from my command line?
      - baybal2 8y ago
        Few companies that used them that I dealt with had their own tooling, but that was nothing special. CI picks up your image build, then commits its record to a DB from which DHCP server looks up a boot image for given MAC, then it either SSHed a reboot command or used an IPMI reboot. Voila Today, some server motherboard firmwares can boot images off HTTP, vlan, and can talk with the boot server itself on HTTP
        tasubotadas 8y ago
        Much more straightforward than docker!
      - fatherlinnux 8y ago
        You could have if HashiCorp had beaten Docker to market with a simple VagrantHub and bud tool... It could have easily been VMs instead of containers. IMHO, it was all the packaging...
      - syn0byte 8y ago
        ~$ qemu diskimage.img
- ex_amazon_sde 8y ago
  Former Amazon engineer here. Despite the downvotes, you are making an excellent point. Amazon, among other FAANG companies, never needed containers shipping entire bundled OSes. Deploying a "base OS" (using PXE or netboot) can be done very reliably both on a hypervisors and VMs. A simple build system can then generate traditional packages and push them into VMs allocated for a specific product. It provides better security isolation and the ability to receive security updates on OSes and also on dynamically linked libraries. Building and deploying new versions of you product is also much faster, especially at large scale: only your application package is rebuilt and deployed.
  - manigandham 8y ago
    That's technically what companies with refined processes do by using "scratch" docker images that only contain the binaries needed for the application and nothing else. The fact that many other containers run entire OS is because it's easier to get started, or there are runtimes needed, or people just build and deploy in the same image.
    - fatherlinnux 8y ago
      I agree that developed companies are doing what is described, but that is a completely separate thing than starting from scratch. People have hurriedly forgotten why Linux distros exist: https://opensource.com/article/19/2/linux-distributions-still-matter-containers https://opensource.com/article/19/2/linux-distributions-stil... Even when you write a lot of software, environments always drag in existing tools and infrastructure (aka other open source). 99% it's easier to consume pre-built SME knowledge from. Linux distro #HailTheMaintainers
nickjj 8y ago
Exactly. I see Docker as a framework. It's the "get me from nothing" to a fully featured solution for building, running and distributing containerized applications. And it happens to do it for anyone running Windows, MacOS or Linux. It's the same reason why I would want to use a web framework. I don't necessarily want to write and string together a bunch of super low level things. I want to start at a higher level of abstraction so I can focus on writing the applications I care about. As an end user, I don't necessarily care too much about OCI or the runtime spec. I care about running docker-compose up and having everything work.
- detaro 8y ago
  The article is about the company, not the product. Which bits of what Docker provides would you pay for, given free alternatives exist now for basically all of it?
  - raesene9 8y ago
    To be fair, the article is about both. To quote "in my humble opinion the days for Docker as a company are numbered and maybe also a technology as well."
  - nickjj 8y ago
    I don't think I would pay for any of the core features, but that's mainly because I've been using Docker for 5 years with the current strategy of just about everything is open source. You pay if you want support and other enterprise features. Private hub repos are also reasonable to buy for most people because it's priced pretty competitively with rolling your own private registry on a cloud provider (ie. $7 / month for 5 repos isn't much more than $5 / month for the cheapest DO droplet but now you need to manage that machine yourself which is not worth the hassle for $2 less).
    - weberc2 8y ago
      I would pay for an ecosystem of images that are vetted for security issues. They could even build an industry around security and privacy compliance and certification, which risk-averse companies (and those who want to do business with them) would pay for.
tyingq 8y ago
"Why would that be the case?" One argument could be that their moat is mostly brand. And, increasingly, other brands are working around them. Like Kubernetes. They already offer non-docker runtimes. They could, at some point, offer and promote their own packaging tool too. People might use a K8S tool solely because it's the "default setting".
- Aeolun 8y ago
  I have a ton of docker images already that work perfectly fine. Why would I switch to something else?
  - ATsch 8y ago
    These container images will continue to work.
  - johannes1234321 8y ago
    There will be more created in the future, than was in the past.
  - fatherlinnux 8y ago
    The OCI standards make it so that it doesn't matter if you switch or not. Your images will work anywhere with any tool (aka Cloud Providers, Kubernetes, Podman, Buildah, etc.) Everybody has OCI compliant tools, even Docker - Docker founded the OCI.
    - Aeolun 8y ago
      Same point though. If docker works, why switch to anything else?
      - tyingq 8y ago
        "The Kubernetes project is excited to announce kocker, a new docker compatible image management tool. Kocker will support features you've been asking for, like non-priv-by-default containers, enhanced performance in k8s..." Made up, but I imagine something like that.
stingraycharles 8y ago
You're missing the point of the author. It's not so much that Docker as a technology is bad; there's nothing wrong with it. The point is that Docker, the company, cannot monetize upon the technology, because the moment they start charging for their containerization technology, people will switch to an alternative container technology, especially now that Kubernetes has won the orchestration "wars" and made it so easy to switch the underlying technology. Personally, I have to agree with the author and think it's difficult to see a bright future for the company that lives up to its $1.3B valuation.
- darkerside 8y ago
  Would a $32B valuation of Red Hat make you reconsider?
  - outside1234 8y ago
    No that just means IBM was dumb - and also no container talent
    - pjmlp 8y ago
      Linux containers have a lot to learn from mainframe containers.
  - alexandre_m 8y ago
    That's a good point, there's huge market demand for technology and talent in the cloud native space. However I don't see how Docker Inc can be substainable in the long run. What's most likely to happen is Docker being acqui-hired by someone like Microsoft.
- triplewipeass 8y ago
  The story of Docker, Inc should be read as a cautionary tale to those who think that every random bit of open source should be “monetized” by seeking rent for its continued use and support.
StreamBright 8y ago
> What’s wrong with Docker? Why would I want to switch to something else? Security, performance, reliability and following best engineering practices. Everything else is fine. https://arxiv.org/pdf/1804.05039.pdf https://arxiv.org/pdf/1804.05039.pdf https://hackernoon.com/another-reason-why-your-docker-containers-may-be-slow-d37207dec27f https://hackernoon.com/another-reason-why-your-docker-contai... https://www.scylladb.com/2018/08/09/cost-containerization-scylla/ https://www.scylladb.com/2018/08/09/cost-containerization-sc... https://thehftguy.com/2017/02/23/docker-in-production-an-update/ https://thehftguy.com/2017/02/23/docker-in-production-an-upd... http://catern.com/posts/docker.html http://catern.com/posts/docker.html
- tasubotadas 8y ago
  It's kinda useless when it's not compared against alternatives. A crappy working solution is infinitely times better than an ideal non-working one (like Linux vs Hurd).
  - eeZah7Ux 8y ago
    The alternative solution has been working for decades: software packaging.
    - gtirloni 8y ago
      Not even remotely accessible to end users like containers are today.
    - weberc2 8y ago
      Except it hasn't been working; with few exceptions we still deal with dependency hell / isolation issues in system package managers. Surely if it worked as well as you posit we would have long ago had a Kubernetes built upon apt or yum?
      - StreamBright 8y ago
        I am not sure if you have experience working with one of the leading tech companies but most of the problems you mention were solved long time ago, before containers were a thing. Apt and yum are not the right set of tools for this job, Amazon for example had an internal build and deployment system that solved dependency problems as well as environment variables, configuration management and additional aspects that even Kubernetes does not solve today.
013a 8y ago
> Why would I want to switch to something else? The core argument is that you wouldn't care if you were using something else. I use Kubernetes. That's what I care about. If I'm on AKS, GKE, EKS, any other managed Kubernetes service, the only time I ever even see the word Docker is in the filename of the Dockerfile. They could switch their default runtime to anything else and I might not notice. > 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? This is the exact same problem that Oracle has with Java, and MongoDB now has with their product. You can't make money off of an API, and implementation's are very rarely a differentiator. Another product will come along (actually, several already exist) that says "we support dockerfiles, we emulate the docker api, swap us out". There's nothing new to learn. The only thing that product needs is a benefit over normal docker, and if you think Amazon, Google, or Microsoft can't add value through more native integration with their cloud services, you're crazy. Docker isn't going anywhere, but they become commoditized far too quickly than their valuation would suggest.
takeda 8y ago
Docker is drifting towards being a standardizes deployment unit. This is especially apparent with advent of Alpine Linux based images or even more so with distroless. With these changes going on, docker becomes just a fancy zip file, and since now there is a committee to design a standardized container there really is nothing left for for the Docker company. Kubernetes IMO just used Docker's popularity to gain its own, but at this point the actual docker itself is no longer essential.

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).
pilooch 8y ago
One reason I see as an open source developer is low touch adoption and environment control. Over with build support on many Linux flavors (redhat from the past, archlinux from the ghetto :) ), use dockerized version instead. This might be my narrow corner of the world but users have driven me to dockerize much of what I do code, and my support hassle has lowered, a lot.
zenexer 8y ago
That sounds like a pretty solid system, but it’s not at all what the author is advocating. The author states that Docker is destined to be replaced by other containerization frameworks. The functionality differences won’t be as stark as what you’ve described, so this isn’t really a good comparison. That being said, I’d agree that netboot + tmpfs has a lot of advantages; unfortunately, it’s not always practical, especially at smaller scales. Containers are convenient and don’t require any special hardware accommodations.
StreamBright 8y ago
Exactly, we have POCed Docker and realised we have a solution for every aspect that it is trying to address. I found one and exactly one use case for Docker, running CI/CD workload.
tasubotadas 8y ago
You kinda missed the point that docker is more about packaging the applications than running them. Running apps is easy. Packaging in such a way that they could be run without hassle - hard.
- baybal2 8y ago
  > could be run without hassle - hard. Strict versioning of every dependency - exactly the thing a packaging system solves. Specific system configuration? Also not a problem at all with netboot images.
  - Aeolun 8y ago
    Can I run netboot images anywhere easily from my command line?
    - baybal2 8y ago
      Few companies that used them that I dealt with had their own tooling, but that was nothing special. CI picks up your image build, then commits its record to a DB from which DHCP server looks up a boot image for given MAC, then it either SSHed a reboot command or used an IPMI reboot. Voila Today, some server motherboard firmwares can boot images off HTTP, vlan, and can talk with the boot server itself on HTTP
      - tasubotadas 8y ago
        Much more straightforward than docker!
    - fatherlinnux 8y ago
      You could have if HashiCorp had beaten Docker to market with a simple VagrantHub and bud tool... It could have easily been VMs instead of containers. IMHO, it was all the packaging...
    - syn0byte 8y ago
      ~$ qemu diskimage.img
ex_amazon_sde 8y ago
Former Amazon engineer here. Despite the downvotes, you are making an excellent point. Amazon, among other FAANG companies, never needed containers shipping entire bundled OSes. Deploying a "base OS" (using PXE or netboot) can be done very reliably both on a hypervisors and VMs. A simple build system can then generate traditional packages and push them into VMs allocated for a specific product. It provides better security isolation and the ability to receive security updates on OSes and also on dynamically linked libraries. Building and deploying new versions of you product is also much faster, especially at large scale: only your application package is rebuilt and deployed.
- manigandham 8y ago
  That's technically what companies with refined processes do by using "scratch" docker images that only contain the binaries needed for the application and nothing else. The fact that many other containers run entire OS is because it's easier to get started, or there are runtimes needed, or people just build and deploy in the same image.
  - fatherlinnux 8y ago
    I agree that developed companies are doing what is described, but that is a completely separate thing than starting from scratch. People have hurriedly forgotten why Linux distros exist: https://opensource.com/article/19/2/linux-distributions-still-matter-containers https://opensource.com/article/19/2/linux-distributions-stil... Even when you write a lot of software, environments always drag in existing tools and infrastructure (aka other open source). 99% it's easier to consume pre-built SME knowledge from. Linux distro #HailTheMaintainers

nickjj 8y ago

Exactly. I see Docker as a framework. It's the "get me from nothing" to a fully featured solution for building, running and distributing containerized applications. And it happens to do it for anyone running Windows, MacOS or Linux. It's the same reason why I would want to use a web framework. I don't necessarily want to write and string together a bunch of super low level things. I want to start at a higher level of abstraction so I can focus on writing the applications I care about. As an end user, I don't necessarily care too much about OCI or the runtime spec. I care about running docker-compose up and having everything work.

detaro 8y ago
The article is about the company, not the product. Which bits of what Docker provides would you pay for, given free alternatives exist now for basically all of it?
- raesene9 8y ago
  To be fair, the article is about both. To quote "in my humble opinion the days for Docker as a company are numbered and maybe also a technology as well."
- nickjj 8y ago
  I don't think I would pay for any of the core features, but that's mainly because I've been using Docker for 5 years with the current strategy of just about everything is open source. You pay if you want support and other enterprise features. Private hub repos are also reasonable to buy for most people because it's priced pretty competitively with rolling your own private registry on a cloud provider (ie. $7 / month for 5 repos isn't much more than $5 / month for the cheapest DO droplet but now you need to manage that machine yourself which is not worth the hassle for $2 less).
  - weberc2 8y ago
    I would pay for an ecosystem of images that are vetted for security issues. They could even build an industry around security and privacy compliance and certification, which risk-averse companies (and those who want to do business with them) would pay for.

tyingq 8y ago

"Why would that be the case?" One argument could be that their moat is mostly brand. And, increasingly, other brands are working around them. Like Kubernetes. They already offer non-docker runtimes. They could, at some point, offer and promote their own packaging tool too. People might use a K8S tool solely because it's the "default setting".

Aeolun 8y ago
I have a ton of docker images already that work perfectly fine. Why would I switch to something else?
- ATsch 8y ago
  These container images will continue to work.
- johannes1234321 8y ago
  There will be more created in the future, than was in the past.
- fatherlinnux 8y ago
  The OCI standards make it so that it doesn't matter if you switch or not. Your images will work anywhere with any tool (aka Cloud Providers, Kubernetes, Podman, Buildah, etc.) Everybody has OCI compliant tools, even Docker - Docker founded the OCI.
  - Aeolun 8y ago
    Same point though. If docker works, why switch to anything else?
    - tyingq 8y ago
      "The Kubernetes project is excited to announce kocker, a new docker compatible image management tool. Kocker will support features you've been asking for, like non-priv-by-default containers, enhanced performance in k8s..." Made up, but I imagine something like that.

stingraycharles 8y ago

You're missing the point of the author. It's not so much that Docker as a technology is bad; there's nothing wrong with it. The point is that Docker, the company, cannot monetize upon the technology, because the moment they start charging for their containerization technology, people will switch to an alternative container technology, especially now that Kubernetes has won the orchestration "wars" and made it so easy to switch the underlying technology. Personally, I have to agree with the author and think it's difficult to see a bright future for the company that lives up to its $1.3B valuation.

darkerside 8y ago
Would a $32B valuation of Red Hat make you reconsider?
- outside1234 8y ago
  No that just means IBM was dumb - and also no container talent
  - pjmlp 8y ago
    Linux containers have a lot to learn from mainframe containers.
- alexandre_m 8y ago
  That's a good point, there's huge market demand for technology and talent in the cloud native space. However I don't see how Docker Inc can be substainable in the long run. What's most likely to happen is Docker being acqui-hired by someone like Microsoft.
triplewipeass 8y ago
The story of Docker, Inc should be read as a cautionary tale to those who think that every random bit of open source should be “monetized” by seeking rent for its continued use and support.

StreamBright 8y ago

> What’s wrong with Docker? Why would I want to switch to something else? Security, performance, reliability and following best engineering practices. Everything else is fine. https://arxiv.org/pdf/1804.05039.pdf https://arxiv.org/pdf/1804.05039.pdf https://hackernoon.com/another-reason-why-your-docker-containers-may-be-slow-d37207dec27f https://hackernoon.com/another-reason-why-your-docker-contai... https://www.scylladb.com/2018/08/09/cost-containerization-scylla/ https://www.scylladb.com/2018/08/09/cost-containerization-sc... https://thehftguy.com/2017/02/23/docker-in-production-an-update/ https://thehftguy.com/2017/02/23/docker-in-production-an-upd... http://catern.com/posts/docker.html http://catern.com/posts/docker.html

tasubotadas 8y ago
It's kinda useless when it's not compared against alternatives. A crappy working solution is infinitely times better than an ideal non-working one (like Linux vs Hurd).
- eeZah7Ux 8y ago
  The alternative solution has been working for decades: software packaging.
  - gtirloni 8y ago
    Not even remotely accessible to end users like containers are today.
  - weberc2 8y ago
    Except it hasn't been working; with few exceptions we still deal with dependency hell / isolation issues in system package managers. Surely if it worked as well as you posit we would have long ago had a Kubernetes built upon apt or yum?
    - StreamBright 8y ago
      I am not sure if you have experience working with one of the leading tech companies but most of the problems you mention were solved long time ago, before containers were a thing. Apt and yum are not the right set of tools for this job, Amazon for example had an internal build and deployment system that solved dependency problems as well as environment variables, configuration management and additional aspects that even Kubernetes does not solve today.

013a 8y ago

> Why would I want to switch to something else? The core argument is that you wouldn't care if you were using something else. I use Kubernetes. That's what I care about. If I'm on AKS, GKE, EKS, any other managed Kubernetes service, the only time I ever even see the word Docker is in the filename of the Dockerfile. They could switch their default runtime to anything else and I might not notice. > 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? This is the exact same problem that Oracle has with Java, and MongoDB now has with their product. You can't make money off of an API, and implementation's are very rarely a differentiator. Another product will come along (actually, several already exist) that says "we support dockerfiles, we emulate the docker api, swap us out". There's nothing new to learn. The only thing that product needs is a benefit over normal docker, and if you think Amazon, Google, or Microsoft can't add value through more native integration with their cloud services, you're crazy. Docker isn't going anywhere, but they become commoditized far too quickly than their valuation would suggest.

takeda 8y ago

Docker is drifting towards being a standardizes deployment unit. This is especially apparent with advent of Alpine Linux based images or even more so with distroless. With these changes going on, docker becomes just a fancy zip file, and since now there is a committee to design a standardized container there really is nothing left for for the Docker company. Kubernetes IMO just used Docker's popularity to gain its own, but at this point the actual docker itself is no longer essential.