12 ms·

Less complicated software -> less complicated deployments -> less complicated systems -> fewer vulnerabilities. It's a mathematical fact.

tptacek 7y ago
Deploying your less-complicated design consistently through automation reduces complexity; it doesn’t increase it. I don’t think we are operating from similar definitions of “mathematical fact”.
- ddevault 7y ago
  Some automation is good, but no one reaches for these tools because they need "some" automation. They do it because they have already obscenely over-complex applications which require these levels of complexity just to stand them up. Or worse, they don't have that level of complexity, but they use these tools anyway, which means that they account for more than half of the software's complexity in the first place.
  - tptacek 7y ago
    That’s not what you said upthread. Salt, k8s, Ansible: they’re all the same. That’s what you said.
    - ddevault 7y ago
      I don't understand how anything that I've said is in opposition to my original point.
      - tptacek 7y ago
        "Some automation is good" is not a statement compatible with (here I paraphrase) "tools that run a consistent set of shell commands on an arbitrary set of machines are the same as tools that install resident agents on those machines". It's OK if you didn't know how Salt (or Ansible, maybe) worked, but you should just acknowledge that and move on rather than doubling down.
        ddevault 7y ago
        Don't resort to acusations of ignorance just because you aren't making your point effectively. I have hands-on experience with every tool I've mentioned except for k8s, which isn't being discussed in detail. I am under no illusions that the security profile of Salt vs Ansible is different. If that's all you're getting at, then fine, I concede, do your little victory lap. My point is and has been much broader: these tools solve the same class of problems which are symptoms of a broken culture, and solve them poorly. It's no surprise to me that any and all of them have problems, have had problems, and will have more problems - because they're broken by design, and they "solve" problems that we shouldn't have.
- gnufx 6y ago
  Well, I can manage a system running hundreds or thousands of heterogeneous stateless nodes consistently from an image essentially simply managed "by hand" (maybe with judicious help from things like package auto-updates). Otherwise I could add something like Ansible with its configuration -- probably rather larger -- similarly managed by hand. Obviously the latter increases complexity and scope for problems; observationally it also decreases reliability and availability. Substantial experience says the simple way is the best to manage HPC systems, in particular, and it generalizes, like to managing teaching "clusters" with few resources[1]. There are minimal trades-off from just using things you already know -- package management, revision control, and initrd/pivot_root -- against using tools which are distinctly non-trivial, but make you look good for solving the extra problems and justify more manpower. I've used a cluster-building system from a maintainer and contributors with Ansible expertise and been unpleasantly surprised, if not as much as by several cluster vendors' products. Of course you automate things like monitoring, alerts, and some problem mitigation, for which simple configuration management frees effort. Accidental and essential complexity, someone once talked about. 1. http://workshop.openafs.org/afsbpw09/thu_2_1.html http://workshop.openafs.org/afsbpw09/thu_2_1.html
qqssccfftt 7y ago
Not using software -> more human interaction -> more human error -> more vulnerabilities. It's a mathematical fact.

tptacek 7y ago

Deploying your less-complicated design consistently through automation reduces complexity; it doesn’t increase it. I don’t think we are operating from similar definitions of “mathematical fact”.

ddevault 7y ago
Some automation is good, but no one reaches for these tools because they need "some" automation. They do it because they have already obscenely over-complex applications which require these levels of complexity just to stand them up. Or worse, they don't have that level of complexity, but they use these tools anyway, which means that they account for more than half of the software's complexity in the first place.
- tptacek 7y ago
  That’s not what you said upthread. Salt, k8s, Ansible: they’re all the same. That’s what you said.
  - ddevault 7y ago
    I don't understand how anything that I've said is in opposition to my original point.
    - tptacek 7y ago
      "Some automation is good" is not a statement compatible with (here I paraphrase) "tools that run a consistent set of shell commands on an arbitrary set of machines are the same as tools that install resident agents on those machines". It's OK if you didn't know how Salt (or Ansible, maybe) worked, but you should just acknowledge that and move on rather than doubling down.
      - ddevault 7y ago
        Don't resort to acusations of ignorance just because you aren't making your point effectively. I have hands-on experience with every tool I've mentioned except for k8s, which isn't being discussed in detail. I am under no illusions that the security profile of Salt vs Ansible is different. If that's all you're getting at, then fine, I concede, do your little victory lap. My point is and has been much broader: these tools solve the same class of problems which are symptoms of a broken culture, and solve them poorly. It's no surprise to me that any and all of them have problems, have had problems, and will have more problems - because they're broken by design, and they "solve" problems that we shouldn't have.
gnufx 6y ago
Well, I can manage a system running hundreds or thousands of heterogeneous stateless nodes consistently from an image essentially simply managed "by hand" (maybe with judicious help from things like package auto-updates). Otherwise I could add something like Ansible with its configuration -- probably rather larger -- similarly managed by hand. Obviously the latter increases complexity and scope for problems; observationally it also decreases reliability and availability. Substantial experience says the simple way is the best to manage HPC systems, in particular, and it generalizes, like to managing teaching "clusters" with few resources[1]. There are minimal trades-off from just using things you already know -- package management, revision control, and initrd/pivot_root -- against using tools which are distinctly non-trivial, but make you look good for solving the extra problems and justify more manpower. I've used a cluster-building system from a maintainer and contributors with Ansible expertise and been unpleasantly surprised, if not as much as by several cluster vendors' products. Of course you automate things like monitoring, alerts, and some problem mitigation, for which simple configuration management frees effort. Accidental and essential complexity, someone once talked about. 1. http://workshop.openafs.org/afsbpw09/thu_2_1.html http://workshop.openafs.org/afsbpw09/thu_2_1.html

qqssccfftt 7y ago

Not using software -> more human interaction -> more human error -> more vulnerabilities. It's a mathematical fact.