4 ms·

I agree that deployment isn't a UX problem, but I think having a one-button (or one-command) deployment process is a goal that leads to more reliable and safer

I agree that deployment isn't a UX problem, but I think having a one-button (or one-command) deployment process is a goal that leads to more reliable and safer deployments. The vast majority of consumer applications can (and should) be able to deploy in one command. There's complexity behind deployments, but it's complexity that's almost always best handled by automation.

siliconc0w 9y ago
Automating complexity doesn't remove it, it just hides it and adds some overhead (code that needs to be tested, debugged, and maintained). The operator of the tool should be power users who (mostly) understand what the tool is doing behind the scenes. Magic buttons encourage people to 'trust the tool' when you really shouldn't. Tools are stupid. Just trying to pop some of the mythology surrounding this stuff. Automation is not a cure-all. You should definitely do it, because operating by hand isn't at all better, but you should probably still know what you're doing and 'magic buttons' can discourage this.
- groby_b 9y ago
  I'm fairly certain the "understanding the stack" argument has been sufficiently addressed by Carl Sagan: https://www.youtube.com/watch?v=7s664NsLeFM https://www.youtube.com/watch?v=7s664NsLeFM We're building abstractions so people can build on top of it. And yes, that includes trusting your tool. When's the last time you ran JTAG debugging on your CPU? Did you use a scope to verify it worked correctly? You should probably have a somewhat decent understanding of the layers close to what you building, but there are plenty of applications where deployment is far removed from what you actually build. That's where the "magic button" matters.
  - siliconc0w 9y ago
    In the Apple Pie scenario, you'll find most apple pie enthusiasts can go down the stack a few layers. They'll talk about important aspects of the right flour, the apples, etc. In the specific case of opsolutely you're in a tight spot because there are several better abstraction options available than your closed source invite only tool. Kube and Mesos both offer better support and tooling and both have several options for an extensible and automated software deployment lifecycle.

siliconc0w 9y ago

Automating complexity doesn't remove it, it just hides it and adds some overhead (code that needs to be tested, debugged, and maintained). The operator of the tool should be power users who (mostly) understand what the tool is doing behind the scenes. Magic buttons encourage people to 'trust the tool' when you really shouldn't. Tools are stupid. Just trying to pop some of the mythology surrounding this stuff. Automation is not a cure-all. You should definitely do it, because operating by hand isn't at all better, but you should probably still know what you're doing and 'magic buttons' can discourage this.

groby_b 9y ago
I'm fairly certain the "understanding the stack" argument has been sufficiently addressed by Carl Sagan: https://www.youtube.com/watch?v=7s664NsLeFM https://www.youtube.com/watch?v=7s664NsLeFM We're building abstractions so people can build on top of it. And yes, that includes trusting your tool. When's the last time you ran JTAG debugging on your CPU? Did you use a scope to verify it worked correctly? You should probably have a somewhat decent understanding of the layers close to what you building, but there are plenty of applications where deployment is far removed from what you actually build. That's where the "magic button" matters.
- siliconc0w 9y ago
  In the Apple Pie scenario, you'll find most apple pie enthusiasts can go down the stack a few layers. They'll talk about important aspects of the right flour, the apples, etc. In the specific case of opsolutely you're in a tight spot because there are several better abstraction options available than your closed source invite only tool. Kube and Mesos both offer better support and tooling and both have several options for an extensible and automated software deployment lifecycle.