6 ms·

In terms of CPU cycles and disk space, maybe. In terms of engineer cycles, absolutely not. Which costs more?

danuker 5y ago
Hmm, a SCP shell script on my laptop, prompting my SSH key's password and deploying the site to the target machine? Or a constantly-updating behemoth, running as root, installing packages from yet another unauditable repository chain?
- hyperhopper 5y ago
  The first option is something custom that you had to write yourself and remember how to use years later, or explain how to use to others The second option is standardized and usually the same 1 or 2 commands to run anywhere
- somenewaccount1 5y ago
  You forgot the step where you had to provision that server to run the software and maintain all the systems security updates on the live running server, and that server requires all the same maintenance, with or without docker. And if you fuck it up, better call the wife and cancell Sunday plans because you forgot how it all gets installed and ......yeah, just use docker :p
  - danuker 5y ago
    Debian offers unattended upgrades: https://wiki.debian.org/UnattendedUpgrades https://wiki.debian.org/UnattendedUpgrades And security updates, as you said, are needed regardless of whether you run Docker on top. I think Docker is a needless complexity and security risk.
    - throwanem 5y ago
      And you're welcome to think so, but if you intend to make a case for removing Docker as optimization, you still have yet to start.
      - danuker 5y ago
        I am arguing against Docker for maintainability reasons, not CPU cycles. Relying on hidden complexity makes for a hard path ahead. You become bound by Docker's decisions to change in the future. For example, SSLPing's reliance on a lot of complex software (among which NodeJS and Docker) got it to close, and it got on the front page of HN recently. https://sslping.com/ https://sslping.com/ https://news.ycombinator.com/item?id=30985514 https://news.ycombinator.com/item?id=30985514 Keeping dependencies to a minimum will extend the useful lifespan of your software.
        throwanem 5y ago
        Docker Swarm isn't Docker; it's an orchestration service on top of Docker, that happens to have originated with the same organization that Docker does - hence the name. A few years ago Swarm looked like it might be competitive in the container orchestration space, but then Kubernetes got easy to use even for the small deployments Swarm also targeted, and Swarm has withered since. It wouldn't be impossible or probably even all that difficult to switch over to k8s if that were the only blocker, but as the sunset post notes and you here ignore, that wasn't the only or the worst problem facing SSLping - as, again, the sunset post notes to your apparent disinterest, it's been losing money for quite a while before it fell apart. (Has it occurred to you that it losing money for a while might have contributed to its eventual unmaintainability, as the dev opted sensibly to work on more sustainably remunerative projects? If so, why ignore it? If not, why not?) Similarly for the Node aspect - that's very much a corner use case related to this specific application (normally SSLv3 support is something you actively don't want!), and not something that can fairly be generalized into an indictment of Node overall. Not that it's a surprise to see anyone unjustly indict Node on the basis of an unsupportable generalization from a corner case! But that it's unsurprising constitutes no excuse. Other than that you seem here to rely on truisms, with no apparent effort to demonstrate how they apply in the context of the argument at which you gesture. And even the truisms are misapplied! Avoiding dependencies for the sake of avoiding dependencies produces unmaintainable software because you and your team are responsible for every aspect of everything, and that can work for a team of Adderall-chomping geniuses, but also only works for a team of Adderall-chomping geniuses. Good for you if you can arrange that, but it's quite absurd to imagine that generalizes or scales.
    - lolinder 5y ago
      Security updates are only needed on the OS level if you're running Docker on bare metal or a VPS. If you're running Docker in a managed container or managed Kubernetes service such as ECS/EKS, you only need to update the Docker image itself, which is as simple as updating your pip/npm/maven/cargo/gem/whatever dependencies. I see two main places where Docker provides a lot of value: in a large corp where you have massive numbers of developers running diverse services on shared infrastructure, and in a tiny org where you don't have anyone who is responsible for maintaining your infrastructure full time. The former benefits from a standardized deployment unit that works easily with any language/stack. The latter benefits from being able to piggy-back off a cloud provider that handles the physical and OS infrastructure for you.
deleted 5y ago
[deleted]
marginalia_nu 5y ago
Building simpler systems allows you to save on all three.
- throwanem 5y ago
  That's true, but in my experience there is nothing mutually exclusive in systems being simple and systems running Docker. Granted, you do need to learn how Docker works, and be ready to help others do likewise if you're onboarding folks with little or no prior experience of Docker to a team where Docker is used. That's certainly a tradeoff you face with Docker - just as with literally every other shared tool, platform, codebase, language, or technological application of any kind. The question that wants asking is whether, in exchange for that increased effort of pedagogy, you get something that makes the increased effort worthwhile. I think in a lot of cases you do, and my experience has borne that out; software in containers isn't materially more difficult to maintain than software outside it if you know what you're doing, and in many cases it's much easier. I get that not everyone is going to agree with me here, nor do I demand everyone should. But it would be nice if someone wanted to take the time to argue the other side of my claim, rather than merely insisting upon it with no more evident basis than arbitrarily selected first principles given no further consideration in the context of what I continue to hope may develop into a discussion.
  - marginalia_nu 5y ago
    Docker is absolutely ups the complexity. Whatever set-up your application needs is a still necessary step in the process. But now you've not only added more software in docker with its a docker registry, and Docker's state on top of the application's state, you've also introduced multiple virtual filesystems and a layer of mapping between those and locations on the host, mappings between the container's ports and the host's ports. There is no longer a single truth about the host system. The application may see one thing and you, the owner, another. If the application says "I wrote it to /foo/bar", you may look in "/foo/bar" and find that /foo doesn't even exist. All of that is indirection and new ways things can be that did not exist if you just ran your code natively. What is complexity if not additional layers of indirection and the increase of ways things can be?

Hmm, a SCP shell script on my laptop, prompting my SSH key's password and deploying the site to the target machine? Or a constantly-updating behemoth, running as root, installing packages from yet another unauditable repository chain?

hyperhopper 5y ago
The first option is something custom that you had to write yourself and remember how to use years later, or explain how to use to others The second option is standardized and usually the same 1 or 2 commands to run anywhere
somenewaccount1 5y ago
You forgot the step where you had to provision that server to run the software and maintain all the systems security updates on the live running server, and that server requires all the same maintenance, with or without docker. And if you fuck it up, better call the wife and cancell Sunday plans because you forgot how it all gets installed and ......yeah, just use docker :p
- danuker 5y ago
  Debian offers unattended upgrades: https://wiki.debian.org/UnattendedUpgrades https://wiki.debian.org/UnattendedUpgrades And security updates, as you said, are needed regardless of whether you run Docker on top. I think Docker is a needless complexity and security risk.
  - throwanem 5y ago
    And you're welcome to think so, but if you intend to make a case for removing Docker as optimization, you still have yet to start.
    - danuker 5y ago
      I am arguing against Docker for maintainability reasons, not CPU cycles. Relying on hidden complexity makes for a hard path ahead. You become bound by Docker's decisions to change in the future. For example, SSLPing's reliance on a lot of complex software (among which NodeJS and Docker) got it to close, and it got on the front page of HN recently. https://sslping.com/ https://sslping.com/ https://news.ycombinator.com/item?id=30985514 https://news.ycombinator.com/item?id=30985514 Keeping dependencies to a minimum will extend the useful lifespan of your software.
      - throwanem 5y ago
        Docker Swarm isn't Docker; it's an orchestration service on top of Docker, that happens to have originated with the same organization that Docker does - hence the name. A few years ago Swarm looked like it might be competitive in the container orchestration space, but then Kubernetes got easy to use even for the small deployments Swarm also targeted, and Swarm has withered since. It wouldn't be impossible or probably even all that difficult to switch over to k8s if that were the only blocker, but as the sunset post notes and you here ignore, that wasn't the only or the worst problem facing SSLping - as, again, the sunset post notes to your apparent disinterest, it's been losing money for quite a while before it fell apart. (Has it occurred to you that it losing money for a while might have contributed to its eventual unmaintainability, as the dev opted sensibly to work on more sustainably remunerative projects? If so, why ignore it? If not, why not?) Similarly for the Node aspect - that's very much a corner use case related to this specific application (normally SSLv3 support is something you actively don't want!), and not something that can fairly be generalized into an indictment of Node overall. Not that it's a surprise to see anyone unjustly indict Node on the basis of an unsupportable generalization from a corner case! But that it's unsurprising constitutes no excuse. Other than that you seem here to rely on truisms, with no apparent effort to demonstrate how they apply in the context of the argument at which you gesture. And even the truisms are misapplied! Avoiding dependencies for the sake of avoiding dependencies produces unmaintainable software because you and your team are responsible for every aspect of everything, and that can work for a team of Adderall-chomping geniuses, but also only works for a team of Adderall-chomping geniuses. Good for you if you can arrange that, but it's quite absurd to imagine that generalizes or scales.
  - lolinder 5y ago
    Security updates are only needed on the OS level if you're running Docker on bare metal or a VPS. If you're running Docker in a managed container or managed Kubernetes service such as ECS/EKS, you only need to update the Docker image itself, which is as simple as updating your pip/npm/maven/cargo/gem/whatever dependencies. I see two main places where Docker provides a lot of value: in a large corp where you have massive numbers of developers running diverse services on shared infrastructure, and in a tiny org where you don't have anyone who is responsible for maintaining your infrastructure full time. The former benefits from a standardized deployment unit that works easily with any language/stack. The latter benefits from being able to piggy-back off a cloud provider that handles the physical and OS infrastructure for you.

deleted 5y ago

[deleted]

marginalia_nu 5y ago

Building simpler systems allows you to save on all three.

throwanem 5y ago
That's true, but in my experience there is nothing mutually exclusive in systems being simple and systems running Docker. Granted, you do need to learn how Docker works, and be ready to help others do likewise if you're onboarding folks with little or no prior experience of Docker to a team where Docker is used. That's certainly a tradeoff you face with Docker - just as with literally every other shared tool, platform, codebase, language, or technological application of any kind. The question that wants asking is whether, in exchange for that increased effort of pedagogy, you get something that makes the increased effort worthwhile. I think in a lot of cases you do, and my experience has borne that out; software in containers isn't materially more difficult to maintain than software outside it if you know what you're doing, and in many cases it's much easier. I get that not everyone is going to agree with me here, nor do I demand everyone should. But it would be nice if someone wanted to take the time to argue the other side of my claim, rather than merely insisting upon it with no more evident basis than arbitrarily selected first principles given no further consideration in the context of what I continue to hope may develop into a discussion.
- marginalia_nu 5y ago
  Docker is absolutely ups the complexity. Whatever set-up your application needs is a still necessary step in the process. But now you've not only added more software in docker with its a docker registry, and Docker's state on top of the application's state, you've also introduced multiple virtual filesystems and a layer of mapping between those and locations on the host, mappings between the container's ports and the host's ports. There is no longer a single truth about the host system. The application may see one thing and you, the owner, another. If the application says "I wrote it to /foo/bar", you may look in "/foo/bar" and find that /foo doesn't even exist. All of that is indirection and new ways things can be that did not exist if you just ran your code natively. What is complexity if not additional layers of indirection and the increase of ways things can be?