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

41–50 of 76 posts

Re: Virtualizing development environments in 2023

#41

Post by zdragnar »

fragmede wrote: post #34
gspencley wrote: post #20

Earlier quoted context omitted.

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

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…

I think this hits the nail on the head. Plenty of companies have software stacks so large / complex to configure that there's no reasonable way to run the entire system on a single laptop.

As much as I dislike the experience of remote dev environments in general, there are certainly times where it may be worth the pain.

Re: Virtualizing development environments in 2023

#42

Post by stephenr »

m463 wrote: post #28
foxbyte wrote: post #15

Consider exploring LXC for a more mature alternative to Docker. It's not confined to the OCI ecosystem and offers a higher degree of isolation for development environments.

LXC doesn't have a Dockerfile concept though. I think a Dockerfile as a recipe for an environment is pretty elegant. I've used LXC with proxmox and managing what's in a container is kind of like being a sysadmin.

There is an LXC provider for vagrant, which gets you the one-file concept, with the benefits that not everyone on the project has to use LXC, they just need a provider that works on their host for the specified base box.

This is vagrants' real superpower.

Re: Virtualizing development environments in 2023

#43

Post by CGamesPlay »

ravenstine wrote: post #16

Good god, no. Or, at least, let us never make this a sort of standard way of developing that you're going to push on to your engineers. Containers have their place, they can be great, but I've tried the whole "containerize everything" approach, and it's no less time consuming than not containers, and now you have another Thing You Have To Learn (TM). This isn't to say that virtualization is a bad thing for a developm…

As a consultant who jumps around between code bases with vastly different requirements, containers make for a much better experience than managing that on my main machine, or spinning up VMs for each separate project. It’s an ideal situation for me.

Re: Virtualizing development environments in 2023

#44

Post by debosmit »

fragmede wrote: post #32
debosmit wrote: post #24

Earlier quoted context omitted.

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-product... ) was to enable the p…

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.

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

Re: Virtualizing development environments in 2023

#45

Post by ranger207 »

scarmig wrote: post #18
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…

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…

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

Re: Virtualizing development environments in 2023

#46

Post by CGamesPlay »

swozey wrote: post #35
CGamesPlay wrote: post #33

Earlier quoted context omitted.

How do you handle tooling? Install it in the parent or in the container? I quite like the idea of VS Code dev containers since it does a lot of the bootstrapping work to make the container be more like a full system, and I wish this “remote environment” idea was more widely supported amongst editors.

Hmm. By tooling are you referring to things like jq and other "uncommon" cli/tui apps I use to work against a code base locally? I think that's what you mean. One of the best practices when using docker-compose to develop is actually to mount your code base as a volume. This lets you modify the code locally without requiring a complete rebuild of the container each time code is modified. You might have to no-hup a se…

Mostly tools that you are going to run during the development process that aren’t going to be run in CI/at “build time”. So sure, possibly jq, but especially language server and editor integrations. Do you run the editor in the container? Do not use these tools?

Re: Virtualizing development environments in 2023

#47

Post by tiew9Vii »

m463 wrote: post #28
foxbyte wrote: post #15

Consider exploring LXC for a more mature alternative to Docker. It's not confined to the OCI ecosystem and offers a higher degree of isolation for development environments.

LXC doesn't have a Dockerfile concept though. I think a Dockerfile as a recipe for an environment is pretty elegant. I've used LXC with proxmox and managing what's in a container is kind of like being a sysadmin.

Docker is cattle, LXC is pets.

Docker packages applications, and should only really have one app inside it. LXC is similar to a vm in it presents itself as a stand-alone machine but uses the host kernel, it’s not like a vm in it’s not as isolated as sharing the host kernel.

So with LXC I agree, managing it is like being a sysadmin as that’s what it’s designed to be.

I use Docker for things that are stateless, maybe throw away, or just test an app quickly. I use LXC for things I want to run multiple services inside, more statefull, typically where people plumb a bunch of Docker images together in I’ll use LXC. The advantage in Proxmox is I tell Proxmos to backup my LXC nightly as it’s treated similar to a VM.

For making LXC feel less like needing to be a sysadmin, you can use Nix to build your LXC images and import in to Proxmox. Your LXC container becomes declarative and not to dissimilar to using a Dockerfile, it’s a far more powerful Dockerfile. What I’ve done is create a bare minimal NixOS LXC with some basic config and use that as a template then edit ‘/etc/nixos/configuration.nix’ inside the LXC on first boot. However as it’s just nixos you can build push the config remotely, use NixOps etc.

It’s a really good workflow using NixOS with LXC however it took me a while to get it as the docs are a bit thin and an old+new version of docs with the new version skipping things mentioned in the old you need to do, I.e change the tty to /dev/console to get a shell inside proxmox console.

Re: Virtualizing development environments in 2023

#48

Post by tempodox »

ranger207 wrote: post #45
scarmig wrote: post #18

Earlier quoted context omitted.

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…

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.

Re: Virtualizing development environments in 2023

#49

Post by ajdude »

Terretta wrote: post #17
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…

See VSCode ssh remote: https://code.visualstudio.com/docs/remote/ssh-tutorial See also: https://code.visualstudio.com/docs/devcontainers/containers People pay for this. https://github.com/features/codespaces

This is exactly what I've been doing. I pay for a vps and just use vscode to do all of my work, I tend to switch between various computers and even various laptops, and it doesn't matter which one I'm on and just ssh into my dev station.

Re: Virtualizing development environments in 2023

#50

Post by scarmig »

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.

Parallels always took that crown in my book, though I don't have that much experience with VirtualBox.
Post reply on HN