Yep! If the workflow is not written out in the README or other docs, then it’s not a supported workflow, and you are on your own.
I disagree with one part. People need to adopt a technology, and they want to get towards actually running it. If the README doesn’t work, or a quick-start script doesn’t get you going, people will change their choices. Only once a user has invested will they invest more in fixing problems. For that, you need to optimize the tutorial.
You don’t need to optimize FOR tutorials, but you do need to optimize the tutorial.
Unrelatedly, after reading your k8s section:
I’d be interested in knowing what you, the author, think of Hashicorp Nomad.
I don’t have setups that scale to hundreds of devs with stateful workloads. But I do run several stateful workloads on top of Nomad, and it works great for me. Am I just oblivious, or is it possible to have constructed a stack without too many sharp edges (like podman did, helping change the OCI container world).
I am increasingly impressed with Nomad as someone who started very skeptical. It’s a world class product that really “just works” and solves a lot of the problems Kubernetes attempted to solve in….frankly a better way.
I don’t think that’s the right cause. A couple of non-programming examples of the same underlying problem:
Glossy screens displaced matte ones in laptops because they look brighter in a shop setting, even though they are significantly worse (reflections and glare) in real use.
Apple found that showing the various animations in OS X 10.0 measurably increased sales. Some of these (e.g. the Genie effect for minimise) had real usability benefits (showing clearly where the window had gone when it vanished) but the shiny animations were the thing that increased sales, so there was an incentive (for Apple and others) to add more gratuitous animations that distracted in normal usage.
Ofc both can be improved, often separately, sometimes together, sometimes at a small cost to one for great gains at the other, but I’m glad there are tools where they have not accepted great costs in usability or quality for learnability.
Yep! If the workflow is not written out in the README or other docs, then it’s not a supported workflow, and you are on your own.
I disagree with one part. People need to adopt a technology, and they want to get towards actually running it. If the README doesn’t work, or a quick-start script doesn’t get you going, people will change their choices. Only once a user has invested will they invest more in fixing problems. For that, you need to optimize the tutorial.
You don’t need to optimize FOR tutorials, but you do need to optimize the tutorial.
Unrelatedly, after reading your k8s section:
I’d be interested in knowing what you, the author, think of Hashicorp Nomad.
I don’t have setups that scale to hundreds of devs with stateful workloads. But I do run several stateful workloads on top of Nomad, and it works great for me. Am I just oblivious, or is it possible to have constructed a stack without too many sharp edges (like podman did, helping change the OCI container world).
I am increasingly impressed with Nomad as someone who started very skeptical. It’s a world class product that really “just works” and solves a lot of the problems Kubernetes attempted to solve in….frankly a better way.
The article is worth reading even just for this insight.
I don’t think that’s the right cause. A couple of non-programming examples of the same underlying problem:
Usability > learnability.
Ofc both can be improved, often separately, sometimes together, sometimes at a small cost to one for great gains at the other, but I’m glad there are tools where they have not accepted great costs in usability or quality for learnability.