4 ms·

Enterprise likes it, because it gives them more visibility and control over what's going on in the dev box. That gives more angles to control against e.g. exfil

Enterprise likes it, because it gives them more visibility and control over what's going on in the dev box. That gives more angles to control against e.g. exfiltration threats. It also makes dev environments much more homogeneous: you worry less about client machines. In principle you could have a fleet of stateless Chromebooks whose main function is ssh and http, all connecting to identical virtualized desktops that are easily provisioned and deprovisioned.

gspencley 3y ago
I agree that enterprise likes it. Developers hate it, though. We are a lot that are very picky about our tools. Virtualization means images means standardization means everyone is using the IDE and tools that IT and "Enterprise" decides. It has it's pros and cons. But one of those cons is that it can make for an intolerable work environment. At least for me. I've gotten to the point where I now ask about dev environment during the interview process. If they mandate Mac or Visual Studio I'm not interested (not trying to start a flame war, those are my personal preferences). I know that certain organizations need their control for auditing, security and remote wipe reasons, and that is understandable. I'll just go work elsewhere. It's fine.
- debosmit 3y ago
  This is really not true - a poor implementation shouldn't dictate the direction of the "remote development" space. Sure, IT and security have their requirements, but primary requirement is to make the developers happy and provide them with reproducible dev environments. I used to work at Uber and what we ended up doing with devpod (https://www.uber.com/blog/devpod-improving-developer-productivity-at-uber/ https://www.uber.com/blog/devpod-improving-developer-product...) was to enable the popular IDEs to connect to these remote environments - all the dotfiles etc etc were persisted so it literally felt like the local IDE, just way faster. Admittedly, it costs a bunch of money to build internally, but there's a path to having people be happy with dev environments. (we collected data on what IDEs to prioritize based on surveys)
  - fragmede 3y ago
    Why use a survey and not just ask the endpoints directly? Presumably the laptops are managed and are running something like Santa on them. Would remove bias to get the data this way.
    - debosmit 3y ago
      yea - we had that too (good for understanding how laptop tooling worked, and what areas were starting to show latencies and therefore, needed to be worked on) surveys were anonymized
- icedchai 3y ago
  When I discover a company prefers Windows desktops, Microsoft 365, and Sharepoint, it's often a red flag for me. I've worked with guys who didn't know how to use git, so they copy all their code into Sharepoint. Then there are others who didn't know how to merge branches, so they copy from one folder to another using the windows desktop. It's even worse when the people doing this are supposedly "senior." In a Linux or Mac environment, I never encounter these sorts of WTFs
  - ElFitz 3y ago
    Just like this company that deployed by mounting the production server on "the special machine" through SMB and dragged and dropped the files across. You couldn’t drag and drop the whole folder, else you’d overwrite the numerous configuration files that were all over the place. I really don’t miss it.
    - icedchai 3y ago
      Yep. I ran into the “don’t overwrite these files” issue on a branch at a new company. It took months to get a sane branching/merging process in place. The “lead” loved copying crap with his windows desktop, did not even script his half baked processes. You should’ve seen what the actual code looked like.
- fragmede 3y ago
  You don't speak for all developers, at least not me. In particular, having a working dev environment that accurately represents prod just handed to you, instead of trying to rig up something locally is actually kinda nice. It matters greatly what you're working on. If you're building a local C++ application, a devbox is going to be wildly inappropriate, but for a SaaS company where prod is a untangleable mess; databases and queues and microservices, it's infinitely more efficient to gave me a box already spun up that's a good enough faxscimile of prod. Bonus points for seeing the DB with test info. In IT, if a user comes to you with a broken mouse, do you try and fix it, or do you just give them a new one and get them back to work asap, and take the mouse in the back and fix it later? Same principle. If the dev box isn't working, it's far easier to spin up a new one rather than debugging on someone's laptop. Dev boxes don't have to mean standardizing on One True Editor (although everyone knows that's vim), as long as you can get to the source, typically via ssh, and edit it, whatever you want to use is just fine.
  - stephenr 3y ago
    If only there were tools to spin up repeatable environments based on a given config file locally, using either VMs or containers, reducing the setup process to a single command. What a world that would be. /s
    - fragmede 3y ago
      If your stack is trivially setup via a docker-compose script, great! there are more complex systems out there for which that's insufficient.
      - xmcqdpt2 3y ago
        I think they meant Nix.
        stephenr 3y ago
        I didn't mean one specific thing. There are numerous tools in this space that approach the problem from different angles using different technologies. My point really, was if your local dev environment requires you to jump through a bunch of hoops doing manual setup to get it working you're doing it wrong.
- justsomehnguy 3y ago
  > Virtualization means images No. Some prefer image based provisioning, but it doesn't mean you can't have your 'own' machine.
- victorbjorklund 3y ago
  I like it. I used gitpod.io before. Super nice to just be able to switch between projects in an easy way. Stopped when they changed pricing though from unlimited time to credits.
ranger207 3y ago
As someone who migrated our devs from local VMs to cloud VMs, I like it because despite the promise that every VM is the same, every dev laptop is not. There's so many ways for Vagrant and VirtualBox to screw up. Sure, the cloud VM is a little slower than local, but at least it fundamentally _works_, unlike VirtualBox where on any given day you might be suffering from any combination of 1) VirtualBox kexts not working on the latest version of MacOS, 2) file sharing silently breaking yet again with no logs, 3) docker containers inside the VM losing network connectivity for the third time this week because the bridge decided it didn't want to do anything, or 4) having VirtualBox installed just completely breaking MacOS and causing a crash during boot even after completely wiping, reloading, and trying to install VirtualBox again. Those are all real issues I spent weeks tearing my hair out over across dozens of devs. Now that we've moved to EC2-based VMs the only problems I have to deal with are minikube problems (which I had to deal with under VirtualBox as well) and when devs forgot they shut down their VM before going on vacation. The devs sometimes don't like that the default EBS volume is a little small, but every one that used the local VM knows it's a small price to pay
- tempodox 3y ago
  Don't use VirtualBox. It's literally the shittiest VM you can choose.
  - scarmig 3y ago
    Parallels always took that crown in my book, though I don't have that much experience with VirtualBox.
  - mhitza 3y ago
    What other option do you have if you want to support developers across Linux/Mac/Windows? VMWare player? Besides it not being OSS, I didn't notice any performance benefit. The bottleneck (for my web development needs), is around the spottiness of shared folders and JS tooling that needs to keep a watch for file changes.
    - stephenr 3y ago

gspencley 3y ago

I agree that enterprise likes it. Developers hate it, though. We are a lot that are very picky about our tools. Virtualization means images means standardization means everyone is using the IDE and tools that IT and "Enterprise" decides. It has it's pros and cons. But one of those cons is that it can make for an intolerable work environment. At least for me. I've gotten to the point where I now ask about dev environment during the interview process. If they mandate Mac or Visual Studio I'm not interested (not trying to start a flame war, those are my personal preferences). I know that certain organizations need their control for auditing, security and remote wipe reasons, and that is understandable. I'll just go work elsewhere. It's fine.

debosmit 3y ago
This is really not true - a poor implementation shouldn't dictate the direction of the "remote development" space. Sure, IT and security have their requirements, but primary requirement is to make the developers happy and provide them with reproducible dev environments. I used to work at Uber and what we ended up doing with devpod (https://www.uber.com/blog/devpod-improving-developer-productivity-at-uber/ https://www.uber.com/blog/devpod-improving-developer-product...) was to enable the popular IDEs to connect to these remote environments - all the dotfiles etc etc were persisted so it literally felt like the local IDE, just way faster. Admittedly, it costs a bunch of money to build internally, but there's a path to having people be happy with dev environments. (we collected data on what IDEs to prioritize based on surveys)
- fragmede 3y ago
  Why use a survey and not just ask the endpoints directly? Presumably the laptops are managed and are running something like Santa on them. Would remove bias to get the data this way.
  - debosmit 3y ago
    yea - we had that too (good for understanding how laptop tooling worked, and what areas were starting to show latencies and therefore, needed to be worked on) surveys were anonymized
icedchai 3y ago
When I discover a company prefers Windows desktops, Microsoft 365, and Sharepoint, it's often a red flag for me. I've worked with guys who didn't know how to use git, so they copy all their code into Sharepoint. Then there are others who didn't know how to merge branches, so they copy from one folder to another using the windows desktop. It's even worse when the people doing this are supposedly "senior." In a Linux or Mac environment, I never encounter these sorts of WTFs
- ElFitz 3y ago
  Just like this company that deployed by mounting the production server on "the special machine" through SMB and dragged and dropped the files across. You couldn’t drag and drop the whole folder, else you’d overwrite the numerous configuration files that were all over the place. I really don’t miss it.
  - icedchai 3y ago
    Yep. I ran into the “don’t overwrite these files” issue on a branch at a new company. It took months to get a sane branching/merging process in place. The “lead” loved copying crap with his windows desktop, did not even script his half baked processes. You should’ve seen what the actual code looked like.
fragmede 3y ago
You don't speak for all developers, at least not me. In particular, having a working dev environment that accurately represents prod just handed to you, instead of trying to rig up something locally is actually kinda nice. It matters greatly what you're working on. If you're building a local C++ application, a devbox is going to be wildly inappropriate, but for a SaaS company where prod is a untangleable mess; databases and queues and microservices, it's infinitely more efficient to gave me a box already spun up that's a good enough faxscimile of prod. Bonus points for seeing the DB with test info. In IT, if a user comes to you with a broken mouse, do you try and fix it, or do you just give them a new one and get them back to work asap, and take the mouse in the back and fix it later? Same principle. If the dev box isn't working, it's far easier to spin up a new one rather than debugging on someone's laptop. Dev boxes don't have to mean standardizing on One True Editor (although everyone knows that's vim), as long as you can get to the source, typically via ssh, and edit it, whatever you want to use is just fine.
- stephenr 3y ago
  If only there were tools to spin up repeatable environments based on a given config file locally, using either VMs or containers, reducing the setup process to a single command. What a world that would be. /s
  - fragmede 3y ago
    If your stack is trivially setup via a docker-compose script, great! there are more complex systems out there for which that's insufficient.
    - xmcqdpt2 3y ago
      I think they meant Nix.
      - stephenr 3y ago
        I didn't mean one specific thing. There are numerous tools in this space that approach the problem from different angles using different technologies. My point really, was if your local dev environment requires you to jump through a bunch of hoops doing manual setup to get it working you're doing it wrong.
justsomehnguy 3y ago
> Virtualization means images No. Some prefer image based provisioning, but it doesn't mean you can't have your 'own' machine.
victorbjorklund 3y ago
I like it. I used gitpod.io before. Super nice to just be able to switch between projects in an easy way. Stopped when they changed pricing though from unlimited time to credits.

ranger207 3y ago

As someone who migrated our devs from local VMs to cloud VMs, I like it because despite the promise that every VM is the same, every dev laptop is not. There's so many ways for Vagrant and VirtualBox to screw up. Sure, the cloud VM is a little slower than local, but at least it fundamentally _works_, unlike VirtualBox where on any given day you might be suffering from any combination of 1) VirtualBox kexts not working on the latest version of MacOS, 2) file sharing silently breaking yet again with no logs, 3) docker containers inside the VM losing network connectivity for the third time this week because the bridge decided it didn't want to do anything, or 4) having VirtualBox installed just completely breaking MacOS and causing a crash during boot even after completely wiping, reloading, and trying to install VirtualBox again. Those are all real issues I spent weeks tearing my hair out over across dozens of devs. Now that we've moved to EC2-based VMs the only problems I have to deal with are minikube problems (which I had to deal with under VirtualBox as well) and when devs forgot they shut down their VM before going on vacation. The devs sometimes don't like that the default EBS volume is a little small, but every one that used the local VM knows it's a small price to pay

tempodox 3y ago
Don't use VirtualBox. It's literally the shittiest VM you can choose.
- scarmig 3y ago
  Parallels always took that crown in my book, though I don't have that much experience with VirtualBox.
- mhitza 3y ago
  What other option do you have if you want to support developers across Linux/Mac/Windows? VMWare player? Besides it not being OSS, I didn't notice any performance benefit. The bottleneck (for my web development needs), is around the spottiness of shared folders and JS tooling that needs to keep a watch for file changes.
  - stephenr 3y ago