That's interesting, thanks for sharing. It's got me interested in trying this out for myself, do you happen to have / know of any other writing about workflows for setting up remote dev environments using prox mox?
* Your remote dev environment doesn't have to be that remote. If it's just you using it, it might be worth it to have that box sitting in a corner at home. You could start out with a 99 dollar nuc, or the old PC you have sitting around, or a cheap desk top, or your companies casts offs (ask, you might be surprised what is getting chucked.
* Prox mox is great, but it's just a pretty GUI on top of some standard linux tools. My adventure down this path started when XEN was the new hotness and it was being run on dell hardware. Pick your poison here.
* VM > Containers. Your host OS doesn't have to match your host os in prod. Your VM should match your host OS in prod. If you want to run containers on that go for it, but I would work with more VM's... The moment you need to jam something into a container for debugging reasons (profiler, network monitor) the VM will have instantly won (cause your logging in and running apt/yum)....
* Find a style that works for you. How do you get your code from your dev system to where it needs to be? Fuse, Rsync, SCP, SFTP, does your IDE allow for remote dev (and are the systems close enough)....
* Figure out how you're going to deal with scripting: bash works great and you can do a lot with it, and make can be helpful. Sometimes you need more than bash (sometimes bash is the wrong tool)... There are a million choices like ansible, chef, puppet... you can sling around biarys (go/zig/rust)... And if your python/ruby/node, you can just install that everywhere. Candidly "portable binary" and a little bash has become the big winner here.
No matter what you read or look at its going to be a month where you feel "unproductive" cause your screwing around with remote dev. In that regard treat it like a new IDE getting set up or learning a new programing language. The reality is that unless you feel like your already a systems admin your going to spend a fair bit of time becoming intimate with infrastructure.
I now just have 6 core 12 thread 128gb am4 sitting in a corner for most of my day to day work. I can clone environments, make risky changes, run tests against them, and then go back work without being out of commission. When I do have compile tasks, those aren't competing with me responding to emails or doing a code review on my personal machine. The pain of setup opens up a LOT of "I can run this experiment" because you're NOT going to mess up your workflow for hours or a day doing them.
* Prox mox is great, but it's just a pretty GUI on top of some standard linux tools. My adventure down this path started when XEN was the new hotness and it was being run on dell hardware. Pick your poison here.
* VM > Containers. Your host OS doesn't have to match your host os in prod. Your VM should match your host OS in prod. If you want to run containers on that go for it, but I would work with more VM's... The moment you need to jam something into a container for debugging reasons (profiler, network monitor) the VM will have instantly won (cause your logging in and running apt/yum)....
* Find a style that works for you. How do you get your code from your dev system to where it needs to be? Fuse, Rsync, SCP, SFTP, does your IDE allow for remote dev (and are the systems close enough)....
* Figure out how you're going to deal with scripting: bash works great and you can do a lot with it, and make can be helpful. Sometimes you need more than bash (sometimes bash is the wrong tool)... There are a million choices like ansible, chef, puppet... you can sling around biarys (go/zig/rust)... And if your python/ruby/node, you can just install that everywhere. Candidly "portable binary" and a little bash has become the big winner here.
No matter what you read or look at its going to be a month where you feel "unproductive" cause your screwing around with remote dev. In that regard treat it like a new IDE getting set up or learning a new programing language. The reality is that unless you feel like your already a systems admin your going to spend a fair bit of time becoming intimate with infrastructure.
I now just have 6 core 12 thread 128gb am4 sitting in a corner for most of my day to day work. I can clone environments, make risky changes, run tests against them, and then go back work without being out of commission. When I do have compile tasks, those aren't competing with me responding to emails or doing a code review on my personal machine. The pain of setup opens up a LOT of "I can run this experiment" because you're NOT going to mess up your workflow for hours or a day doing them.