6 ms·

Allow me to offer a counterpoint. Docker is useful for reasons besides scale. It allows you to (kind of) declaratively define your environment and spin it up i

Allow me to offer a counterpoint. Docker is useful for reasons besides scale. It allows you to (kind of) declaratively define your environment and spin it up in any number of different scenarios. It allows you to ship all your dependencies with your app and not worry about getting the host machine properly configured beyond setting up Docker and/or Kubernetes. Have other apps you want to host on the same set of machines? No problem. When you you pair that with something like alpine Linux, you’re getting a whole lot almost for free.

mherrmann 6y ago
How many scenarios do you typically need to spin up your environment in? I achieve the same (defining the environment) by pinning Python dependencies via requirements.txt and virtual environments. And I have an installation script, like a Dockerfile but just an executable bash script, that installs PostgreSQL etc, pulls the code from GitHub and starts up the server. I can upload this to a clean Debian installation to set up the server, with a well-defined stack, in minutes. > Have other apps you want to host on the same set of machines I don't. I just use one $5 per month Linode for each SaaS. (Or bigger Linodes as the projects get more users. My biggest single box currently serves ~100,000 users.)
- piaste 6y ago
  > I don't. I just use one $5 per month Linode for each SaaS Well then you're basically using VMs as your containerization mechanism, with install scripts replacing Dockerfiles. So from your perspective, don't think of Docker as a really fat binary. Think of it as a stripped-down VM that doesn't cost a minimum of $5 per instance, and comes in a standardized format with a standardized ecosystem around it (package registries, monitoring dashboards, etc.)
  - mherrmann 6y ago
    It's a really fat binary that adds unnecessary layers in both dev and prod. In dev, it's faster to run tests and easier to debug without Docker. And in prod, why use a vm inside a vm?
    - sofixa 6y ago
      > In dev, it's easier to debug without Docker. And in prod, why use a vm inside a vm? On the contrary, it's easier to debug with Docker - it eliminates dangling system level libraries / old dependencies / cache, and everything is self-contained. If you have the problem in dev, you'll have it in prod as well. Docker is not a VM, it's basically a big wrapper around chroot and cgroups, the performance hit is minimal. The advantage is that, again, it's self-contained, so there's little risk some OS / dangling library muddies the waters ( especially in Python that's a great risk -OS level python library installations are a thing, and many a Python library depend on C libraries on the system level, which you can't manage through Python tooling). It's also idempotent ( thus making rollbacks easier) and declarative.
      - mherrmann 6y ago
        I've never encountered this "dangling libraries" problem you describe in the past 7 years of developing web apps. I suspect you are working in different, maybe more specialised, environments than me. For me, it usually is really just pretty standard libraries and dependencies.
      - antidocker 6y ago
        This is wrong. Docker is a VM on Windows at least.
        sofixa 6y ago
        Nobody is talking about Docker on Windows or Mac for production use.
        antidocker 6y ago
        Don't you think Mac are not used in Prod?
    - treekogreen 6y ago
      Containerisation software adds so much more than just a binary with layers of indirection. Easy fine grain control of individual application memory, namespace isolation (container to container communication on a need to know basis), A-B testing, ease of on-boarding, multi-os development, CD pipelines, ease of container restarting etc.
  - antidocker 6y ago
    I use Ansible instead Docker. It make no sense to use Docker at all. Ansible take care of all.
scns 6y ago
Python apps have worse performance, bigger image size and longer build times on Alpine Linux: https://pythonspeed.com/articles/alpine-docker-python/ https://pythonspeed.com/articles/alpine-docker-python/
- johnpython 6y ago
  For running applications in production, Alpine Linux is harmful and should be avoided. Getting a smaller container image is not worth trading mucl for glibc.
  - kingosticks 6y ago
    To a Docker outsider, to me this implies that Alpine for testing and non-Alpine for production is not harmful. Is that right? Wasn't having a unified environment half the point of using Docker? Doesn't two different base systems just open you up to a load of headaches? If so, then isn't it more of a "Alpine Linux as a Docker base is harmful" situation?
- ahmedalsudani 6y ago
  Thank you for sharing that! It has never occurred to me but that makes sense. For my Go/Haskell binaries, I usually do need to make changes in order to get them working. The smaller image size is essential in my use case though so I pay that penalty.
14u2c 6y ago
This is absolutely the case. IMO the main benefit provided by containerization is reproducibility. Scaling and other positives are just a product of this.

mherrmann 6y ago

How many scenarios do you typically need to spin up your environment in? I achieve the same (defining the environment) by pinning Python dependencies via requirements.txt and virtual environments. And I have an installation script, like a Dockerfile but just an executable bash script, that installs PostgreSQL etc, pulls the code from GitHub and starts up the server. I can upload this to a clean Debian installation to set up the server, with a well-defined stack, in minutes. > Have other apps you want to host on the same set of machines I don't. I just use one $5 per month Linode for each SaaS. (Or bigger Linodes as the projects get more users. My biggest single box currently serves ~100,000 users.)

piaste 6y ago
> I don't. I just use one $5 per month Linode for each SaaS Well then you're basically using VMs as your containerization mechanism, with install scripts replacing Dockerfiles. So from your perspective, don't think of Docker as a really fat binary. Think of it as a stripped-down VM that doesn't cost a minimum of $5 per instance, and comes in a standardized format with a standardized ecosystem around it (package registries, monitoring dashboards, etc.)
- mherrmann 6y ago
  It's a really fat binary that adds unnecessary layers in both dev and prod. In dev, it's faster to run tests and easier to debug without Docker. And in prod, why use a vm inside a vm?
  - sofixa 6y ago
    > In dev, it's easier to debug without Docker. And in prod, why use a vm inside a vm? On the contrary, it's easier to debug with Docker - it eliminates dangling system level libraries / old dependencies / cache, and everything is self-contained. If you have the problem in dev, you'll have it in prod as well. Docker is not a VM, it's basically a big wrapper around chroot and cgroups, the performance hit is minimal. The advantage is that, again, it's self-contained, so there's little risk some OS / dangling library muddies the waters ( especially in Python that's a great risk -OS level python library installations are a thing, and many a Python library depend on C libraries on the system level, which you can't manage through Python tooling). It's also idempotent ( thus making rollbacks easier) and declarative.
    - mherrmann 6y ago
      I've never encountered this "dangling libraries" problem you describe in the past 7 years of developing web apps. I suspect you are working in different, maybe more specialised, environments than me. For me, it usually is really just pretty standard libraries and dependencies.
    - antidocker 6y ago
      This is wrong. Docker is a VM on Windows at least.
      - sofixa 6y ago
        Nobody is talking about Docker on Windows or Mac for production use.
        antidocker 6y ago
        Don't you think Mac are not used in Prod?
  - treekogreen 6y ago
    Containerisation software adds so much more than just a binary with layers of indirection. Easy fine grain control of individual application memory, namespace isolation (container to container communication on a need to know basis), A-B testing, ease of on-boarding, multi-os development, CD pipelines, ease of container restarting etc.
- antidocker 6y ago
  I use Ansible instead Docker. It make no sense to use Docker at all. Ansible take care of all.

scns 6y ago

Python apps have worse performance, bigger image size and longer build times on Alpine Linux: https://pythonspeed.com/articles/alpine-docker-python/ https://pythonspeed.com/articles/alpine-docker-python/

johnpython 6y ago
For running applications in production, Alpine Linux is harmful and should be avoided. Getting a smaller container image is not worth trading mucl for glibc.
- kingosticks 6y ago
  To a Docker outsider, to me this implies that Alpine for testing and non-Alpine for production is not harmful. Is that right? Wasn't having a unified environment half the point of using Docker? Doesn't two different base systems just open you up to a load of headaches? If so, then isn't it more of a "Alpine Linux as a Docker base is harmful" situation?
ahmedalsudani 6y ago
Thank you for sharing that! It has never occurred to me but that makes sense. For my Go/Haskell binaries, I usually do need to make changes in order to get them working. The smaller image size is essential in my use case though so I pay that penalty.

14u2c 6y ago

This is absolutely the case. IMO the main benefit provided by containerization is reproducibility. Scaling and other positives are just a product of this.