13 ms·

Like any hyped up technology, Docker gets pitched as an "easy, works out of the box, secure by default solution" but it is almost anything but. But also like an

Like any hyped up technology, Docker gets pitched as an "easy, works out of the box, secure by default solution" but it is almost anything but. But also like any technology, if you take the time to really understand what it is doing and what problems it can solve for you, it can be really awesome to work with. Every "Docker Considered Harmful" post I've read basically boils down to "Why would you use Docker if you can use the 10 technologies it wraps around and manage them yourself instead?" Why would I want to do that if I don't have to? Docker wraps these things well. There are weird defaults and there are some popular patterns in the community that are a bit backwards, but you have the power to work around it. Don't run your containers as root and run a dumb init process in your container. That's half of the posts complaints gone right there. Complaining about defaults is one thing, claiming that bad defaults make a technology "harmful" is just lazy.

bunderbunder 8y ago
> Every "Docker Considered Harmful" post I've read basically boils down to "Why would you use Docker if you can use the 10 technologies it wraps around and manage them yourself instead?" Why would I want to do that if I don't have to? Or if you can't? One feature driving Docker adoption that I think a lot of people miss is that it's got fairly workable (if warty in one case and obnoxious in the other) implementations for OS X and Windows. That removes a lot of friction for developers who work in companies where IT won't support Linux on employee workstations. Sure, your ops team can put together a bunch of stuff manually. And then you can create a bunch of extra stuff that makes it easier for development to handle all of that inside virtual machines, and get the network bridging between those apps and the host machine working properly, and all that fun stuff. And by the time you've got it completed and working nicely, you'll be ready to launch your own Docker competitor onto the market.
- geggam 8y ago
  It empowers developers to side step many of the best practices learned in SDLC over the last 20 years and ship code they shouldn't The code is then running on a fault tolerant platform which masks the bugs and makes ops life hell when it comes to actual debugging. Additionally upgrades and other assumptions about the base OS and system management are simply swept under the carpet with pretending those issues no longer exist. Effectively it makes much much more work when things break and is great when it runs well or you run it in GCP where they take care of that part for you.
  - mmt 8y ago
    > you run it in GCP where they take care of that part for you Although I'm generally inclined to agree with your positions on this thread (biased as I am due to my Ops profession), this doesn't seem like a valid criticism. If Docker-on-GCP actually does address all the issues from the perspective of the developers/customers/users, then it's a plausible solution. The only consideration would be cost.
- ravenstine 8y ago
  > Sure, your ops team can put together a bunch of stuff manually. And then you can create a bunch of extra stuff that makes it easier for development to handle all of that inside virtual machines, and get the network bridging between those apps and the host machine working properly, and all that fun stuff. I think this is one of the biggest reasons people use Docker, although they tend to forget to mention it since it's not exactly a technical advantage of Docker; in many ways, it allows developers to bypass DevOps or sometimes eliminate them all together. No more creating Jira tickets just to have a specific version of Imagemagick installed on a server.
  - bunderbunder 8y ago
    I think it's one of the two biggest reasons. The other, possibly bigger, reason is that it gives you a way to install fairly complex software and have it reasonably configured and running right out of the box. I use Docker to run stuff like PostgreSQL on my dev box. Not so much because it's a technically superior option (in truth, it's slower and eats more memory than installing it directly on my machine) as much as because it reliably lets me get up and running in a few minutes, just the time it takes to download the image, really. All the other options I've tried invariably require some fiddling, especially if you need an older version. I suspect that all the other codepoints that have ever been spilled on the subject are mostly just an attempt to get ops on board with it. (Disclaimer: All above comments are a mix of wild speculation and Freudian projection. I tend to come down against using it in production.)
    - ravenstine 8y ago
      At my work, we've had mixed results using it in production. I'd still prefer to using to avoid Ops, but besides that Docker comes with its own bag of issues even though it eliminates versioning conflicts. For development, on the other hand, I absolutely love it. Being able to have different docker-compose.yml files for each of my projects and being able to spin up isolated versions of database services(each with their own volumes!) has been a tremendous win for me.
  - jonnycoder 8y ago
- philwelch 8y ago
  > One feature driving Docker adoption that I think a lot of people miss is that it's got fairly workable (if warty in one case and obnoxious in the other) implementations for OS X and Windows. That removes a lot of friction for developers who work in companies where IT won't support Linux on employee workstations. Vagrant does this, too. Sure, it runs a VM, but so does Docker.
  - zapita 8y ago
    Vagrant runs a VM per app. Sometimes more. Big difference.
    - paulie_a 8y ago
      Since when? I run multiple apps on vagrant every day. That is pretty standard.
      - zapita 8y ago
        And most likely you are running those multiple apps on multiple VMs.
    - workinthehead 8y ago
      Well, there is a big difference, but not the one you've managed to come up with. Vagrant is normally used to run full VMs (although you can use it to drive Docker), so while you might run App, Supporting App, PHP, Apache, Node, Nginx, MySQL, Mongodb, and Redis all as separate containers, you'd probably put them all on the same VM. Your comment almost makes it sound like you don't understand Vagrant or VMs.
    - HelloNurse 8y ago
      Well, a VM per sensible unit of configuration management the user is supposed to choose. An "app" is a very slippery concept.
  - shaklee3 8y ago
    What does this mean? Docker does not run a VM. It runs cgroups, namespaces, etc.
- codedokode 8y ago
  > implementations for OS X and Windows But they use virutal machines. For me, the disk access speed is very slow for a virtual machine. For example, elasticsearch daemon starts in 8s in Debian on real hardware and takes more than 30s in a VirtualBox. Everything that touches disk works slower.

bunderbunder 8y ago

> Every "Docker Considered Harmful" post I've read basically boils down to "Why would you use Docker if you can use the 10 technologies it wraps around and manage them yourself instead?" Why would I want to do that if I don't have to? Or if you can't? One feature driving Docker adoption that I think a lot of people miss is that it's got fairly workable (if warty in one case and obnoxious in the other) implementations for OS X and Windows. That removes a lot of friction for developers who work in companies where IT won't support Linux on employee workstations. Sure, your ops team can put together a bunch of stuff manually. And then you can create a bunch of extra stuff that makes it easier for development to handle all of that inside virtual machines, and get the network bridging between those apps and the host machine working properly, and all that fun stuff. And by the time you've got it completed and working nicely, you'll be ready to launch your own Docker competitor onto the market.

geggam 8y ago
It empowers developers to side step many of the best practices learned in SDLC over the last 20 years and ship code they shouldn't The code is then running on a fault tolerant platform which masks the bugs and makes ops life hell when it comes to actual debugging. Additionally upgrades and other assumptions about the base OS and system management are simply swept under the carpet with pretending those issues no longer exist. Effectively it makes much much more work when things break and is great when it runs well or you run it in GCP where they take care of that part for you.
- mmt 8y ago
  > you run it in GCP where they take care of that part for you Although I'm generally inclined to agree with your positions on this thread (biased as I am due to my Ops profession), this doesn't seem like a valid criticism. If Docker-on-GCP actually does address all the issues from the perspective of the developers/customers/users, then it's a plausible solution. The only consideration would be cost.
ravenstine 8y ago
> Sure, your ops team can put together a bunch of stuff manually. And then you can create a bunch of extra stuff that makes it easier for development to handle all of that inside virtual machines, and get the network bridging between those apps and the host machine working properly, and all that fun stuff. I think this is one of the biggest reasons people use Docker, although they tend to forget to mention it since it's not exactly a technical advantage of Docker; in many ways, it allows developers to bypass DevOps or sometimes eliminate them all together. No more creating Jira tickets just to have a specific version of Imagemagick installed on a server.
- bunderbunder 8y ago
  I think it's one of the two biggest reasons. The other, possibly bigger, reason is that it gives you a way to install fairly complex software and have it reasonably configured and running right out of the box. I use Docker to run stuff like PostgreSQL on my dev box. Not so much because it's a technically superior option (in truth, it's slower and eats more memory than installing it directly on my machine) as much as because it reliably lets me get up and running in a few minutes, just the time it takes to download the image, really. All the other options I've tried invariably require some fiddling, especially if you need an older version. I suspect that all the other codepoints that have ever been spilled on the subject are mostly just an attempt to get ops on board with it. (Disclaimer: All above comments are a mix of wild speculation and Freudian projection. I tend to come down against using it in production.)
  - ravenstine 8y ago
    At my work, we've had mixed results using it in production. I'd still prefer to using to avoid Ops, but besides that Docker comes with its own bag of issues even though it eliminates versioning conflicts. For development, on the other hand, I absolutely love it. Being able to have different docker-compose.yml files for each of my projects and being able to spin up isolated versions of database services(each with their own volumes!) has been a tremendous win for me.
- jonnycoder 8y ago
philwelch 8y ago
> One feature driving Docker adoption that I think a lot of people miss is that it's got fairly workable (if warty in one case and obnoxious in the other) implementations for OS X and Windows. That removes a lot of friction for developers who work in companies where IT won't support Linux on employee workstations. Vagrant does this, too. Sure, it runs a VM, but so does Docker.
- zapita 8y ago
  Vagrant runs a VM per app. Sometimes more. Big difference.
  - paulie_a 8y ago
    Since when? I run multiple apps on vagrant every day. That is pretty standard.
    - zapita 8y ago
      And most likely you are running those multiple apps on multiple VMs.
  - workinthehead 8y ago
    Well, there is a big difference, but not the one you've managed to come up with. Vagrant is normally used to run full VMs (although you can use it to drive Docker), so while you might run App, Supporting App, PHP, Apache, Node, Nginx, MySQL, Mongodb, and Redis all as separate containers, you'd probably put them all on the same VM. Your comment almost makes it sound like you don't understand Vagrant or VMs.
  - HelloNurse 8y ago
    Well, a VM per sensible unit of configuration management the user is supposed to choose. An "app" is a very slippery concept.
- shaklee3 8y ago
  What does this mean? Docker does not run a VM. It runs cgroups, namespaces, etc.
codedokode 8y ago
> implementations for OS X and Windows But they use virutal machines. For me, the disk access speed is very slow for a virtual machine. For example, elasticsearch daemon starts in 8s in Debian on real hardware and takes more than 30s in a VirtualBox. Everything that touches disk works slower.