6 ms·

> Docker is the single best thing to happen to software deployment in 20 years Something like Docker may eventually hold this title, but Docker itself? Certain

> Docker is the single best thing to happen to software deployment in 20 years Something like Docker may eventually hold this title, but Docker itself? Certainly not. It was simply too poorly executed, both strategically but especially technically. Running production workloads in Docker containers was, is, and will be remembered as nothing short of professional negligence. Often expedient, sometimes worth the risk, but always a liability.

empath75 7y ago
What do you base this on?
asadlionpk 7y ago
Sure docker is not perfect but isn't running docker containers mainstream practice now? I think your response is a bit of exaggeration.
- wokwokwok 7y ago
  Haha... for production workloads? Definitely not. Docker is a lovely developer tool, but it’s not, in my experience, ever been (even with swarm when that was a thing) suitable for production workloads. Containers: yes. Docker: that’s a container runtime, and definitely not mainstream for production workloads.
  - marktangotango 7y ago
    I’ve wondered about this myself. What is the solution? On premise cloud like openstack?
  - derefr 7y ago
    I think, when people are talking about "using Docker", they're talking about using Docker tooling to build and push/update/pull Docker images (actually OCI images) around. They're not really talking about running OCI images "on the Docker daemon container runtime." But to most people, OCI images are "Docker" and if your cloud scheduler/hypervisor can run them then it's "a Docker runtime."
    - wokwokwok 7y ago
      I like to believe most people are sufficiently with-the-plot to appreciate that there is a difference between a "container", "container runtime", "container orchestration" and "docker". No one is seriously confused about "using docker" meaning, oh hey, I run my containers on kubernetes. I have literally never met someone who was confused about this. I suppose some people just stop at "I use docker" and don't know what that means when it hits production... but I'm skeptical they actually think a copy of docker is running out there in prod. ...but to be fair, the parent comment did say that running "docker containers" was mainstream; and fair enough. My point was running containers using docker most certainly is not.
      - asadlionpk 7y ago
        I don't get your point. Isn't docker the default runtime everywhere? k8s uses docker internally, by default. So containers are most certainly run in prod using docker (to be specific docker daemon), are they not?
    - jjeaff 7y ago
      Docker daemon is the default runtime for k8s and k8s is most definitely being used in lots of production environments.
  - manigandham 7y ago
    For many people, Docker = container, created using a Dockerfile and deployed to kubernetes or elsewhere, regardless of the actual runtime underneath.
  - hermanradtke 7y ago
    Pretty sure Google App Engine runs Docker under the hood. It has been a while since I logged into a GAE machine.
    - dgoog 7y ago
      It absolutely does not - please cite this.
  - bsaul 7y ago
    just to make sure i understand what you’re saying : running containers created with the docker tool is ok, and running it with kubernetes is also ok, but actually deploying docker tool on a server to run the container is not. Am i correct ? Care to explain what makes that docker tool/runtime unsuitable for production ?
  - raesene9 7y ago
    you're kidding right? Docker runs as the Container Runtime under most Kubernetes clusters (in fact every Kubernetes cluster I've seen). The only other CRIs that are commonly used are CRI-O and ContainerD (which Docker already uses), and last I saw CRI-O was < 10% of the Container runtime market.
  - MagicWishMonkey 7y ago
    What is the problem with using a container based approach for production workloads?
  - jensvdh 7y ago
    Most of the industry runs Docker containers in production my dude.
- pjmlp 7y ago
  Around here it is still plain old VMs, thank you very much.
  - asadlionpk 7y ago
    Both have their usecases. It just doesn't make sense to carry around a VM image (or build a new VM image on each push) for a fairly simple web app (which is what many work on).
    - pjmlp 7y ago
      Well, that is what application servers are for.
sargun 7y ago
There are a non-zero number of deployments that run Docker at considerable scale with pretty good success. I think their software has made considerable strides.
dgoog 7y ago
not enough people are willing to say this out loud because the circus of incompetent voices is too loud docker/k8s are total disasters
gerbilly 7y ago
Yeah, totally agree. Most uses of Docker are of the "Junk Drawer" variety. A bunch of disorganized unpinned dependencies get thrown into a container that will work in a reproducible manner only until one of the upstream deps changes. This approach also allows people to get away with deploying an app without truly understanding it. That's always been a good recipe for success. Another poster claimed that it's mainstream practise, so what? So was running your web-server on 90s era IIS. Not that that was good idea either.
- imtringued 7y ago
  How is this different compared to creating a new VM for every single application?
  - gerbilly 7y ago
    IDK, I don't use docker or a separate VM per application. I guess I'm old school but I install the stuff on my linux instance or server and work out the dependencies so they don't clash. I haven't found it that difficult. Just cos the devs want to throw some ill conceived container over the fence onto my systems, doesn't mean I let them. ( I mean I guess they can, but only if they get the support calls instead of me.)
    - vasco 7y ago
      This sounds like an immature attitude to take towards the people that work with you and just makes you sound like the stereotypical basement sysadmin that needs to control everything and knows better than everyone else.
      - kortilla 7y ago
        Containers are terrible for bureaucratic institutions. It moves security patch management to the development org that builds the containers and development orgs typically don’t have the tooling/process to do this. Source: consulted for a company that got bitten by allowing containers without a patch management process for vulnerabilities.
nine_k 7y ago
Without Docker being so convenient for developers, it would be hard to containerize production. One should not miss the importance of running Docker under Windows or OSX natively, with a VM running Linux tucked behind the scenes. It makes developers' experience so much nicer, and compatible across platforms. This helps adoptions a lot. Time and again, path to mass adoption is not technical excellence, but making an important thing stupidly easy, when one has no excuses not to try.
tarsinge 7y ago
We are a small agency. Before Docker you can’t imagine the pain of managing Python, Ruby or whatever environments and dependencies especially on designers laptops for running dev environments. Now on a fresh laptop it’s just install the Mac desktop client and docker-compose up. Seriously it was a blessing for us.
- sagichmal 7y ago
  If working at your org requires me to spin up Docker containers to write, test, and commit code, I'm changing jobs ASAP. Docker is a tool for CI environments, not for developer laptops (or production, for that matter).
  - tarsinge 7y ago
    I should have been more clear that it’s mostly for non developers (designers) or front-end developers for running the back-end, without the hassle of installing and maintint the related development environment. The same as if it was a third party program. If you still install a full ecosystem every time you want to try a piece of code in any language in Github instead of doing docker run I think you are missing something. With that said I too use it in my dev machine and don’t really see the downsides for the kind of projects I work on, so I’m curious if you can explain your opinion.
    - sagichmal 7y ago
      Most programmers bring value to an organization by creating and maintaining code. Code should therefore be organized so that programmers have to interact with the fewest possible artifacts (repos, compilation units, deployment artifacts, processes) to deliver that value, ideally 1. (This is symmetric with Conway's Law.) Delivering value on that single artifact should be possible in isolation, meaning (after cloning) without internet access, or any other service running on the development environment. Concretely, all services should have a "development mode" that allows them to exercise their business logic against mock or stub dependent services, in-process/in-mem databases, etc. So, > If you still install a full ecosystem every time you want to try a piece of code in any language in Github instead of doing docker run I think you are missing something. If I'm working at a company, I expect that delivering business value means checking out, compiling, running, and testing a single process with no external dependencies. If this isn't the case, I will make it the case, before starting any value-delivering work. If delivering business value requires me to spin up the entire universe of services on my laptop, creating a miniature staging or production environment, that's a problem that needs to be fixed. This means that docker-compose, in fact Docker at all (unless the business value involves e.g. Linux-specific features), Kubernetes, etc. in my build/test/run cycle are all red flags. Exceptions exist, but they are and should be rare.

empath75 7y ago

What do you base this on?

asadlionpk 7y ago

Sure docker is not perfect but isn't running docker containers mainstream practice now? I think your response is a bit of exaggeration.

wokwokwok 7y ago
Haha... for production workloads? Definitely not. Docker is a lovely developer tool, but it’s not, in my experience, ever been (even with swarm when that was a thing) suitable for production workloads. Containers: yes. Docker: that’s a container runtime, and definitely not mainstream for production workloads.
- marktangotango 7y ago
  I’ve wondered about this myself. What is the solution? On premise cloud like openstack?
- derefr 7y ago
  I think, when people are talking about "using Docker", they're talking about using Docker tooling to build and push/update/pull Docker images (actually OCI images) around. They're not really talking about running OCI images "on the Docker daemon container runtime." But to most people, OCI images are "Docker" and if your cloud scheduler/hypervisor can run them then it's "a Docker runtime."
  - wokwokwok 7y ago
    I like to believe most people are sufficiently with-the-plot to appreciate that there is a difference between a "container", "container runtime", "container orchestration" and "docker". No one is seriously confused about "using docker" meaning, oh hey, I run my containers on kubernetes. I have literally never met someone who was confused about this. I suppose some people just stop at "I use docker" and don't know what that means when it hits production... but I'm skeptical they actually think a copy of docker is running out there in prod. ...but to be fair, the parent comment did say that running "docker containers" was mainstream; and fair enough. My point was running containers using docker most certainly is not.
    - asadlionpk 7y ago
      I don't get your point. Isn't docker the default runtime everywhere? k8s uses docker internally, by default. So containers are most certainly run in prod using docker (to be specific docker daemon), are they not?
  - jjeaff 7y ago
    Docker daemon is the default runtime for k8s and k8s is most definitely being used in lots of production environments.
- manigandham 7y ago
  For many people, Docker = container, created using a Dockerfile and deployed to kubernetes or elsewhere, regardless of the actual runtime underneath.
- hermanradtke 7y ago
  Pretty sure Google App Engine runs Docker under the hood. It has been a while since I logged into a GAE machine.
  - dgoog 7y ago
    It absolutely does not - please cite this.
- bsaul 7y ago
  just to make sure i understand what you’re saying : running containers created with the docker tool is ok, and running it with kubernetes is also ok, but actually deploying docker tool on a server to run the container is not. Am i correct ? Care to explain what makes that docker tool/runtime unsuitable for production ?
- raesene9 7y ago
  you're kidding right? Docker runs as the Container Runtime under most Kubernetes clusters (in fact every Kubernetes cluster I've seen). The only other CRIs that are commonly used are CRI-O and ContainerD (which Docker already uses), and last I saw CRI-O was < 10% of the Container runtime market.
- MagicWishMonkey 7y ago
  What is the problem with using a container based approach for production workloads?
- jensvdh 7y ago
  Most of the industry runs Docker containers in production my dude.
pjmlp 7y ago
Around here it is still plain old VMs, thank you very much.
- asadlionpk 7y ago
  Both have their usecases. It just doesn't make sense to carry around a VM image (or build a new VM image on each push) for a fairly simple web app (which is what many work on).
  - pjmlp 7y ago
    Well, that is what application servers are for.

sargun 7y ago

There are a non-zero number of deployments that run Docker at considerable scale with pretty good success. I think their software has made considerable strides.

dgoog 7y ago

not enough people are willing to say this out loud because the circus of incompetent voices is too loud docker/k8s are total disasters

gerbilly 7y ago

Yeah, totally agree. Most uses of Docker are of the "Junk Drawer" variety. A bunch of disorganized unpinned dependencies get thrown into a container that will work in a reproducible manner only until one of the upstream deps changes. This approach also allows people to get away with deploying an app without truly understanding it. That's always been a good recipe for success. Another poster claimed that it's mainstream practise, so what? So was running your web-server on 90s era IIS. Not that that was good idea either.

imtringued 7y ago
How is this different compared to creating a new VM for every single application?
- gerbilly 7y ago
  IDK, I don't use docker or a separate VM per application. I guess I'm old school but I install the stuff on my linux instance or server and work out the dependencies so they don't clash. I haven't found it that difficult. Just cos the devs want to throw some ill conceived container over the fence onto my systems, doesn't mean I let them. ( I mean I guess they can, but only if they get the support calls instead of me.)
  - vasco 7y ago
    This sounds like an immature attitude to take towards the people that work with you and just makes you sound like the stereotypical basement sysadmin that needs to control everything and knows better than everyone else.
    - kortilla 7y ago
      Containers are terrible for bureaucratic institutions. It moves security patch management to the development org that builds the containers and development orgs typically don’t have the tooling/process to do this. Source: consulted for a company that got bitten by allowing containers without a patch management process for vulnerabilities.

nine_k 7y ago

Without Docker being so convenient for developers, it would be hard to containerize production. One should not miss the importance of running Docker under Windows or OSX natively, with a VM running Linux tucked behind the scenes. It makes developers' experience so much nicer, and compatible across platforms. This helps adoptions a lot. Time and again, path to mass adoption is not technical excellence, but making an important thing stupidly easy, when one has no excuses not to try.

tarsinge 7y ago

We are a small agency. Before Docker you can’t imagine the pain of managing Python, Ruby or whatever environments and dependencies especially on designers laptops for running dev environments. Now on a fresh laptop it’s just install the Mac desktop client and docker-compose up. Seriously it was a blessing for us.

sagichmal 7y ago
If working at your org requires me to spin up Docker containers to write, test, and commit code, I'm changing jobs ASAP. Docker is a tool for CI environments, not for developer laptops (or production, for that matter).
- tarsinge 7y ago
  I should have been more clear that it’s mostly for non developers (designers) or front-end developers for running the back-end, without the hassle of installing and maintint the related development environment. The same as if it was a third party program. If you still install a full ecosystem every time you want to try a piece of code in any language in Github instead of doing docker run I think you are missing something. With that said I too use it in my dev machine and don’t really see the downsides for the kind of projects I work on, so I’m curious if you can explain your opinion.
  - sagichmal 7y ago
    Most programmers bring value to an organization by creating and maintaining code. Code should therefore be organized so that programmers have to interact with the fewest possible artifacts (repos, compilation units, deployment artifacts, processes) to deliver that value, ideally 1. (This is symmetric with Conway's Law.) Delivering value on that single artifact should be possible in isolation, meaning (after cloning) without internet access, or any other service running on the development environment. Concretely, all services should have a "development mode" that allows them to exercise their business logic against mock or stub dependent services, in-process/in-mem databases, etc. So, > If you still install a full ecosystem every time you want to try a piece of code in any language in Github instead of doing docker run I think you are missing something. If I'm working at a company, I expect that delivering business value means checking out, compiling, running, and testing a single process with no external dependencies. If this isn't the case, I will make it the case, before starting any value-delivering work. If delivering business value requires me to spin up the entire universe of services on my laptop, creating a miniature staging or production environment, that's a problem that needs to be fixed. This means that docker-compose, in fact Docker at all (unless the business value involves e.g. Linux-specific features), Kubernetes, etc. in my build/test/run cycle are all red flags. Exceptions exist, but they are and should be rare.