4 ms·

Not a fan of the 'one button deploy'. People treat this as a UX problem when it really isn't. By creating magical buttons you're just abstracting a lot of hid

Not a fan of the 'one button deploy'. People treat this as a UX problem when it really isn't. By creating magical buttons you're just abstracting a lot of hidden complication, not removing it. The functionality of an application is governed by an often complex interaction of code, configuration, and various types of persisted and ephemeral state that needs to be understood by the operator. Often the best UX for controlling this complexity is a CLI tool. The CLI is not your enemy.

ben_jones 10y ago
I'd counter that it isn't about the magic button but about the right visual interface for making decisions. Interfaces, whether it's a piece of Java code or a web GUI or something, are very hard to get right. But when you have the perfect interface for something things just flow. IMO the problem with CLIs is that they are so explicit with their feedback you have to know exactly what the command does and can rarely intuitively predict what the right next command should be. And what if your CLI has to be used by a second language english speaker? git rebase –onto <basecommit> HEAD~1 HEAD? Eventually it digresses to long lists of magic black box commands to get your OPs running. Cough every Kubernetes demo ever. Theres a million dollars for the first anthropologist with a deep understanding of human nature to apply their trade to devops. It's not a magic button. It's not a CLI with a -h that reads like a text book. It's something we haven't thought of yet because we're so buried in our own world and established ways of doing things.
- siliconc0w 10y ago
  Git is actually a great example - if you just memorize a few magic git commands you really aren't using the tool correctly and can end up in state that is unrecoverable (at least to you, the magician). Better to spend an afternoon understanding how git works (again, mostly) and be equipped to survive such circumstances.
iEchoic 10y ago
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 10y 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 10y 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 10y 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.

ben_jones 10y ago

I'd counter that it isn't about the magic button but about the right visual interface for making decisions. Interfaces, whether it's a piece of Java code or a web GUI or something, are very hard to get right. But when you have the perfect interface for something things just flow. IMO the problem with CLIs is that they are so explicit with their feedback you have to know exactly what the command does and can rarely intuitively predict what the right next command should be. And what if your CLI has to be used by a second language english speaker? git rebase –onto <basecommit> HEAD~1 HEAD? Eventually it digresses to long lists of magic black box commands to get your OPs running. Cough every Kubernetes demo ever. Theres a million dollars for the first anthropologist with a deep understanding of human nature to apply their trade to devops. It's not a magic button. It's not a CLI with a -h that reads like a text book. It's something we haven't thought of yet because we're so buried in our own world and established ways of doing things.

siliconc0w 10y ago
Git is actually a great example - if you just memorize a few magic git commands you really aren't using the tool correctly and can end up in state that is unrecoverable (at least to you, the magician). Better to spend an afternoon understanding how git works (again, mostly) and be equipped to survive such circumstances.

iEchoic 10y ago

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 10y 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 10y 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 10y 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.