Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Virtualizing development environments in 2023

hocus.dev

Post reply on HN
Print view View original

61–70 of 76 posts

Re: Virtualizing development environments in 2023

#61

Post by fragmede »

stephenr wrote: post #39
fragmede wrote: post #34

Earlier quoted context omitted.

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; databa…

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

If your stack is trivially setup via a docker-compose script, great! there are more complex systems out there for which that's insufficient.

Re: Virtualizing development environments in 2023

#62

Post by mhitza »

tempodox wrote: post #48
ranger207 wrote: post #45

Earlier quoted context omitted.

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 workin…

Don't use VirtualBox. It's literally the shittiest VM you can choose.

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.

Re: Virtualizing development environments in 2023

#63

Post by rvdginste »

I prefer having a powerful development machine and install and use development environments natively. The only times I am prepared to use a (local or remote) VM is when the development environment cannot be installed on the OS of my development machine, or when I absolutely do not want to install those tools natively (because they might impact my main OS).

I am often involved with multiple projects at the same time, but if those projects are set up well (and the toolset is decent), that does not cause any issues. In practice that means that developers always have to take into account that the project itself includes references to the specific versions of the tools that the project needs. And that those tools are -as-much-as-possible- installed in the context of those projects instead of in the context of the whole machine.

A concrete example in node world is to use "nvm" and to always install tools locally in the context of a project instead of globally. In dotnet world, use global.json to specify the version of the tools you want to work with, install dotnet tools locally in the context of a project instead of globally.

I have worked on projects where this is a problem. For example, projects that depend on hardcoded paths. Or projects that depend on hardcoded connection strings for a database. Or projects that do not use something like nvm to specify the version of node/npm they are compatible with.

Each of those things is an issue with the setup of the project and is something that you will bump against when you try to setup a CI/CD pipeline for the project. Although, I agree that it can be useful to use docker containers with a correct version of the tools to create builds in a build pipeline.

The reason that I prefer to develop natively is that it is faster, snappier and more enjoyable. I also believe that it is easier to diagnose issues and investigate performance. Aside from that, renting a virtual machine with the same performance as my development machine, would be a lot more expensive, and I would still have to deal with the lag. I am aware of recent changes that allow you to for example run a JetBrains IDE locally (similar to what VSCode already had for a long time?) that is connected with a remote headless version of the IDE. I do not have any experience with that kind of setup yet, but I assume that would remove most of the lag.

Re: Virtualizing development environments in 2023

#64

Post by black3r »

stephenr wrote: post #40
black3r wrote: post #31

Earlier quoted context omitted.

If you work from the same computer in the same place everyday there are no advantages to having a remote box... If you work 50:50 from office & home you start getting annoyed by either having a different environment at home & work or by having to drag your laptop around with you... If you're a digital nomad wanting to work while travelling through "cheaper" parts of the world it's less worrying to carry around a $500…

> you start getting annoyed ... by having to drag your laptop around with you I'm sorry but you just lost me completely. If you're not taking a laptop with you, what's the fucking point of having a laptop?

it was an either/or statement.., if you don't have a remote devbox your choice is either having to deal with the fact that your home work environment is different from your work environment at the office and you have to set up lots of things twice and encounter some weird issues even if you try to keep them in sync (more problematic for less experienced devs in fast moving companies), or your choice is using a laptop and carrying it with you even if you do have a more powerful PC at home, have the option of having a more powerful desktop at work and would otherwise prefer desktops to laptops...

Re: Virtualizing development environments in 2023

#65

Post by stephenr »

black3r wrote: post #64
stephenr wrote: post #40

Earlier quoted context omitted.

> you start getting annoyed ... by having to drag your laptop around with you I'm sorry but you just lost me completely. If you're not taking a laptop with you, what's the fucking point of having a laptop?

it was an either/or statement.., if you don't have a remote devbox your choice is either having to deal with the fact that your home work environment is different from your work environment at the office and you have to set up lots of things twice and encounter some weird issues even if you try to keep them in sync (more problematic for less experienced devs in fast moving companies), or your choice is using a laptop…

Automated reproducible VMs are pretty straight forward with vagrant, and "setup the same thing from a defined set of instructions" is basically the definition of docker.

But if you're not happy with that scenario - I don't know maybe your work will be drastically affected if you have two different but identical VMs - tb3/4 external ssds are perfect for storing VMs on, so that you can move between machines at the drop of a hat. I've been doing this for about 5 years as a safety valve to my desktop having a fault: I can just unplug the drive and plug it into the laptop or a new machine and the VMs are all there exactly as I left them.

Re: Virtualizing development environments in 2023

#66

Post by icedchai »

ElFitz wrote: post #58
icedchai wrote: post #30

Earlier quoted context omitted.

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 o…

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.

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.

Re: Virtualizing development environments in 2023

#67

Post by black3r »

stephenr wrote: post #65
black3r wrote: post #64

Earlier quoted context omitted.

it was an either/or statement.., if you don't have a remote devbox your choice is either having to deal with the fact that your home work environment is different from your work environment at the office and you have to set up lots of things twice and encounter some weird issues even if you try to keep them in sync (more problematic for less experienced devs in fast moving companies), or your choice is using a laptop…

Automated reproducible VMs are pretty straight forward with vagrant, and "setup the same thing from a defined set of instructions" is basically the definition of docker. But if you're not happy with that scenario - I don't know maybe your work will be drastically affected if you have two different but identical VMs - tb3/4 external ssds are perfect for storing VMs on, so that you can move between machines at the drop…

Doing a reproducible build with Vagrant and Docker is possible but very far from straight forward as you have to make extra sure that you use the exact same source box/image and install every software in the exact same version and deal with updates manually (and while most of the time updates don't break stuff anymore, it still happens at least once a year) + you still have to deal with synchronizing your IDE settings, secrets & credentials which you don't want baked into a Docker image, ... again yes it's possible, but not as straightforward as working in the exact same environment...

the VM on an external SSD is a better solution, but then it's still something you have to carry with you even though it's more compact than a laptop...

Re: Virtualizing development environments in 2023

#68

Post by xmcqdpt2 »

fragmede wrote: post #61
stephenr wrote: post #39

Earlier quoted context omitted.

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

If your stack is trivially setup via a docker-compose script, great! there are more complex systems out there for which that's insufficient.

I think they meant Nix.

Re: Virtualizing development environments in 2023

#69

Post by atq2119 »

black3r wrote: post #31
stephenr wrote: post #14

This whole article is weird to me. I don't really understand the point of a "dev box" that's hosted in a DC and shared, at all - at least not the way they're painting it here. Hardware capabilities for even consumer level laptops and desktops have progressed much faster than average network connections. Having testing/preview/branch named environments in a DC? Sure. But this line: > They should be able to run any sof…

If you work from the same computer in the same place everyday there are no advantages to having a remote box... If you work 50:50 from office & home you start getting annoyed by either having a different environment at home & work or by having to drag your laptop around with you... If you're a digital nomad wanting to work while travelling through "cheaper" parts of the world it's less worrying to carry around a $500…

As someone who has actually traveled through "cheaper" parts of the world, I couldn't imagine working without a local environment. Cheaper parts of the world often imply worse internet connections, spotty wifi, and so on. Requiring a stable internet connection for everything would have been a productivity killer.

Re: Virtualizing development environments in 2023

#70

Post by pushtheenvelope »

black3r wrote: post #64
stephenr wrote: post #40

Earlier quoted context omitted.

> you start getting annoyed ... by having to drag your laptop around with you I'm sorry but you just lost me completely. If you're not taking a laptop with you, what's the fucking point of having a laptop?

it was an either/or statement.., if you don't have a remote devbox your choice is either having to deal with the fact that your home work environment is different from your work environment at the office and you have to set up lots of things twice and encounter some weird issues even if you try to keep them in sync (more problematic for less experienced devs in fast moving companies), or your choice is using a laptop…

blackr, if you'd allow a small plug: we develop https://jetpack.io/devbox for this very scenario.

Devbox will give you the same project environment (packages, env-vars) on your work and home laptop. It leverages nix, and uses your native file-system avoiding the overhead and complexity of using Docker.

Post reply on HN