4 ms·

I think the author is doing it wrong personally. Just spin up a real dev cluster and use that? Why putz around with setups on your laptop? That’s never going to

I think the author is doing it wrong personally. Just spin up a real dev cluster and use that? Why putz around with setups on your laptop? That’s never going to scale team-wise? And if you damn well insist on running your own local k8s cluster for development then the whole thing should be automated infrastructure as code anyways that you start with a command so that other developers will get the same behavior. Even after local dev the changes should be getting picked up and tested by a testing cluster. I think leaving it up to devs to come up with their own local testing k8s is asking for bugs.

rooam-dev 7y ago
Ability to run locally a production like setup (at smaller scale of course) is a big plus imho. 1st, you know how it works, 2nd smaller iterations/feedaback cycles (restart locally vs. push and wait for tests to run).
- hmottestad 7y ago
  I agree with this. But usually you have both. A staging/test environment is nice, but if you have 5 developers and one test env then devs will quickly end up in line waiting for the test env to free up. Remote debugging is also hard. Much easier when running locally.
  - LaGrange 7y ago
    The idea is that you have a dev cluster _per developer_. I've ran with something similar way back working for a certain notable Perl shop way before k8s/Docker became popular, and I have to say it has a lot going for it, especially for more complex setups and more annoying database stuff. It was an (on-demand one-click provisioned) _VM_ per service per dev, though, so the biggest annoyance (no code reload, slow fs sync) was nullified by popular preference for either Vim or Emacs — with my current preference for VS Code I'd probably be annoyed by it. Also it's a bit expensive, I guess, but you can stuff a lot of VMs into a single big server.

4 ms·

I think the author is doing it wrong personally. Just spin up a real dev cluster and use that? Why putz around with setups on your laptop? That’s never going to

by rexarex 7y ago

rooam-dev 7y ago
Ability to run locally a production like setup (at smaller scale of course) is a big plus imho. 1st, you know how it works, 2nd smaller iterations/feedaback cycles (restart locally vs. push and wait for tests to run).
- hmottestad 7y ago
  I agree with this. But usually you have both. A staging/test environment is nice, but if you have 5 developers and one test env then devs will quickly end up in line waiting for the test env to free up. Remote debugging is also hard. Much easier when running locally.
  - LaGrange 7y ago
    The idea is that you have a dev cluster _per developer_. I've ran with something similar way back working for a certain notable Perl shop way before k8s/Docker became popular, and I have to say it has a lot going for it, especially for more complex setups and more annoying database stuff. It was an (on-demand one-click provisioned) _VM_ per service per dev, though, so the biggest annoyance (no code reload, slow fs sync) was nullified by popular preference for either Vim or Emacs — with my current preference for VS Code I'd probably be annoyed by it. Also it's a bit expensive, I guess, but you can stuff a lot of VMs into a single big server.