24 ms·

Sometimes I've spent hours on a single config line, so having to write 20 of some unknown thing sounds scary. And it's irrelevant for what he is trying to do,

Sometimes I've spent hours on a single config line, so having to write 20 of some unknown thing sounds scary. And it's irrelevant for what he is trying to do, which is to run something locally. With docker that's one command, vs having to set up all the other stuff as well. I've been very fan of using docker for all our dev stuff. To run something locally before it meant having correct version of lots of stuff, and possible having installed some database, configure it correctly etc. Onboarding could be days of configuring this stuff and having something fail. Now it's just download docker, run our ./setup.sh that spins up the various docker images, and one's almost good to go.

joana035 6y ago
Well, looks like some fundamental knowledge is missing here, that why everything looks like "hell" or is "scary". I wonder how many lines from this "./setup.sh" could have been avoided by trying a bit harder to understand how the ingress object works. I no longer see lazyness as a good trait in programing.
- matsemann 6y ago
  You are missing the point. In this hypothetical case I'm not interested in knowing how Kubernetes works or is deployed, I'm only interested in running my tools. It's not laziness, it's pragmatism so I can solve what I'm actually trying to solve.
TuringNYC 6y ago
The challenge especially once you get to requiring Ingress Controllers is they are not a core part of Kubernetes, but third party. So you have NGINX, Kong, Traefik -- over a half dozen in total. Not all are fully featured in their open source form, so in some cases you need to purchase the tool to do something like url-rewrite. In some cases, the solution exists, but is something contributed via community (better than none, great in theory, but brittle given the pace of platform change.) Further, once you actually try to spend time on it, you find there is little to no documentation on topics such as url-rewrite. It is all interesting, but then you realize you actually have deadlines -- and now you've spent half the day on futzing around with annotation permutations (since there are few/no docs) and you have not actually started working on the actual task of tuning a model on PyTorch...that is when you drop down to just 'docker run...' It is all worth learning, and doing, but only if you need to. If I need to make something -- in this story Jupyter+PyTorch -- work for many people and be elastic and scalable, then sure, i'll go thru the effort. But if I need a throw-away instance for the day, then it is not worth doing.

joana035 6y ago

Well, looks like some fundamental knowledge is missing here, that why everything looks like "hell" or is "scary". I wonder how many lines from this "./setup.sh" could have been avoided by trying a bit harder to understand how the ingress object works. I no longer see lazyness as a good trait in programing.

matsemann 6y ago
You are missing the point. In this hypothetical case I'm not interested in knowing how Kubernetes works or is deployed, I'm only interested in running my tools. It's not laziness, it's pragmatism so I can solve what I'm actually trying to solve.

TuringNYC 6y ago

The challenge especially once you get to requiring Ingress Controllers is they are not a core part of Kubernetes, but third party. So you have NGINX, Kong, Traefik -- over a half dozen in total. Not all are fully featured in their open source form, so in some cases you need to purchase the tool to do something like url-rewrite. In some cases, the solution exists, but is something contributed via community (better than none, great in theory, but brittle given the pace of platform change.) Further, once you actually try to spend time on it, you find there is little to no documentation on topics such as url-rewrite. It is all interesting, but then you realize you actually have deadlines -- and now you've spent half the day on futzing around with annotation permutations (since there are few/no docs) and you have not actually started working on the actual task of tuning a model on PyTorch...that is when you drop down to just 'docker run...' It is all worth learning, and doing, but only if you need to. If I need to make something -- in this story Jupyter+PyTorch -- work for many people and be elastic and scalable, then sure, i'll go thru the effort. But if I need a throw-away instance for the day, then it is not worth doing.