9 ms·

Do you have a database, a queue service, a caching layer (or 3), a session store? If all your app needs is an http server then sure, why bother with docker... B

Do you have a database, a queue service, a caching layer (or 3), a session store? If all your app needs is an http server then sure, why bother with docker... But if it's more complicated than that, it's great to have standard recipes for alignment in local development, a problem docker solves very well

fastball 6y ago
I have most of those things. I just use hosted versions of those things.
- solumos 6y ago
  Even locally?
  - treve 6y ago
    In my case, I run all services locally without docker. apt-get seems to work just fine.
    - DarmokJalad1701 6y ago
      Seems a bit brittle.
      - fastball 6y ago
        Most issues are because of changes between software versions. Some very few are because of environment, but that's what a staging environment is for.
      - taeric 6y ago
        Oddly, most of this brittle nature helps build a more robust product. That is, yes, it will break often in small ways. However, most of the breaks will be from version upgrades or machine changes. The sooner you find those, the better.
      - treve 6y ago
        Honestly, it hasn't been. Probably helps that I run Linux, but would probably do the same on Mac. Managing that extra virtualization layer has always been more pain than just relying on services that are just always there.
  - vulcan01 6y ago
    > database, a queue service, ... a session store I use these three both remote and locally, and start all of these using a simple shell script.
    - zerd 6y ago
      Does the bash script run on Linux, macOS and Windows?
      - phamilton 6y ago
        It does if you run it inside a Linux VM. EDIT: Just to be clear, I am referring to the fact that Docker on Mac and Windows runs inside a Linux VM.
  - w0m 6y ago
    Real men test in production. Others know better.
    - wbl 6y ago
      Everyone has a test environment. The lucky ones have a different environment for prod.
      - solumos 6y ago
        My favorite: "We have a dedicated environment for QA. To save time we also use it for production."
  - wongarsu 6y ago
    We just had a hosted development database, development redis, etc. It works just fine.
Seirdy 6y ago
These things can also be solved by using distro packages and `cp`-ing config files. Docker introduces a ton of complexity into the stack. Using Docker to solve these problems is like hiring a construction company to build a birdhouse. Sure, it'll save you the work of having to build the birdhouse yourself, but...it's major overkill, and could end up costing you more effort than other options. Now, if you were running a complex suite of mircoservices, then there might be a good reason to use containers. But containers are like JavaScript; you shouldn't jump for them before you've weighed your other options.
- boardwaalk 6y ago
  Reproducibility with a well-written Docker image is well worth it over "cp-ing config files" shiver. Docker isn't Kubernetes -- it's not that complicated.
  - u801e 6y ago
    cp-ing config files is typically done by using config management like puppet, chef, ansible, or saltstack via templating based on server type, location, etc.
  - Seirdy 6y ago
    What's so risky about cp-ing config files as opposed to typing "COPY" or mounting a volume in a Dockerfile? If you use a distro like Debian you shouldn't be worried about breaking changes, especially if you're subscribed to updates/relnotes for the critical parts of your stack (e.g., an announcements mailing list). Those are good practices to have regardless of your platform.
  - kvz 6y ago
    Docker images aren’t built in a reproducible way unless you use something like Nix to create them
- efficax 6y ago
  Docker is just a layer on top of cgroups, and Dockerfiles are basically just shell scripts. It doesn't have to be a huge undertaking
nwhatt 6y ago
I think you're pointing out the double-edged sword that is Docker; it's very easy to run and experiment with new technologies, even ones you might not be organizationally ready for. The "local" kafka that you used for a proof of concept is now AWS MSK in production.

fastball 6y ago

I have most of those things. I just use hosted versions of those things.

solumos 6y ago
Even locally?
- treve 6y ago
  In my case, I run all services locally without docker. apt-get seems to work just fine.
  - DarmokJalad1701 6y ago
    Seems a bit brittle.
    - fastball 6y ago
      Most issues are because of changes between software versions. Some very few are because of environment, but that's what a staging environment is for.
    - taeric 6y ago
      Oddly, most of this brittle nature helps build a more robust product. That is, yes, it will break often in small ways. However, most of the breaks will be from version upgrades or machine changes. The sooner you find those, the better.
    - treve 6y ago
      Honestly, it hasn't been. Probably helps that I run Linux, but would probably do the same on Mac. Managing that extra virtualization layer has always been more pain than just relying on services that are just always there.
- vulcan01 6y ago
  > database, a queue service, ... a session store I use these three both remote and locally, and start all of these using a simple shell script.
  - zerd 6y ago
    Does the bash script run on Linux, macOS and Windows?
    - phamilton 6y ago
      It does if you run it inside a Linux VM. EDIT: Just to be clear, I am referring to the fact that Docker on Mac and Windows runs inside a Linux VM.
- w0m 6y ago
  Real men test in production. Others know better.
  - wbl 6y ago
    Everyone has a test environment. The lucky ones have a different environment for prod.
    - solumos 6y ago
      My favorite: "We have a dedicated environment for QA. To save time we also use it for production."
- wongarsu 6y ago
  We just had a hosted development database, development redis, etc. It works just fine.

Seirdy 6y ago

These things can also be solved by using distro packages and `cp`-ing config files. Docker introduces a ton of complexity into the stack. Using Docker to solve these problems is like hiring a construction company to build a birdhouse. Sure, it'll save you the work of having to build the birdhouse yourself, but...it's major overkill, and could end up costing you more effort than other options. Now, if you were running a complex suite of mircoservices, then there might be a good reason to use containers. But containers are like JavaScript; you shouldn't jump for them before you've weighed your other options.

boardwaalk 6y ago
Reproducibility with a well-written Docker image is well worth it over "cp-ing config files" shiver. Docker isn't Kubernetes -- it's not that complicated.
- u801e 6y ago
  cp-ing config files is typically done by using config management like puppet, chef, ansible, or saltstack via templating based on server type, location, etc.
- Seirdy 6y ago
  What's so risky about cp-ing config files as opposed to typing "COPY" or mounting a volume in a Dockerfile? If you use a distro like Debian you shouldn't be worried about breaking changes, especially if you're subscribed to updates/relnotes for the critical parts of your stack (e.g., an announcements mailing list). Those are good practices to have regardless of your platform.
- kvz 6y ago
  Docker images aren’t built in a reproducible way unless you use something like Nix to create them
efficax 6y ago
Docker is just a layer on top of cgroups, and Dockerfiles are basically just shell scripts. It doesn't have to be a huge undertaking

nwhatt 6y ago

I think you're pointing out the double-edged sword that is Docker; it's very easy to run and experiment with new technologies, even ones you might not be organizationally ready for. The "local" kafka that you used for a proof of concept is now AWS MSK in production.