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

51–60 of 76 posts

Re: Virtualizing development environments in 2023

#51

Post by stephenr »

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…

> VirtualBox

Even HashiCorp know vbox is scraping the bottom of the barrel for hypervisors:

> if you are using Vagrant for any real work, VMware providers are recommended since they're well supported and generally more stable and performant than VirtualBox.

Re: Virtualizing development environments in 2023

#52

Post by fbdab103 »

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?

So people can see the stickers of the conferences you have attended?

Re: Virtualizing development environments in 2023

#53

Post by fbdab103 »

tiew9Vii wrote: post #47
m463 wrote: post #28

Earlier quoted context omitted.

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

I have never really looked into LXC. How strong are the security guarantees? Presumably less isolated than a real VM, but with significantly better performance?

I have started to run more and more software inside a VM for better security isolation, but the loss of performance is pretty discouraging. For things that are probably fine, I might be willing to trade some theoretical security benefits.

Re: Virtualizing development environments in 2023

#54

Post by radus »

CGamesPlay wrote: post #33
swozey wrote: post #27

I know this is an article specific to hocus so I don't mean to take away from that but the title is much more open ended and plural so I'd like to ask this - What has been your favorite local dev environment? I personally docker-compose everything w/ .env overrides and I don't really feel like I've ever needed anything more than this.

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.

Devcontainers are indeed the answer if you’re using VSC. I use the docker-outside-docker feature (there’s a few flavors of these) so my app can be defined with docker-compose. The experience is nice once you’ve taken the time to customize your image, settings, and extensions.

Re: Virtualizing development environments in 2023

#55

Post by halfcat »

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…

> Someone, anyone, tell me which hypervisor doesn't enforce a memory limit on VMs?

They don’t mean the memory usage is allowed to grow indefinitely.

They mean, if your laptop has 32 GB RAM, and if your OS and apps consume 20 GB, it’s using 20 GB RAM.

If a VM has 32 GB of vRAM allocated, and the OS is aggressively caching, that VM will consume 32 GB of RAM on the physical host, even if only 20 GB of vRAM is being used within that guest VM.

Of course, every good hypervisor will have a way to prevent this from happening, so the article does seem disingenuous on this point.

Re: Virtualizing development environments in 2023

#56

Post by laurencerowe »

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…

The advantage of docker based developer workflows is that it makes things repeatable. If you’ve ever tried to support a team installing their own dependencies you’ll understand the pain!

If everyone is working in docker in VS Code it’s not a huge jump to have them develop in remote VMs. Now your devs can get setup instantaneously and can use thin and light MacBook Airs instead of heavy MacBook Pros.

Re: Virtualizing development environments in 2023

#57

Post by LispSporks22 »

zdragnar wrote: post #41
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…

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.

> have software stacks so large / complex to configure

I think that’s your problem right there

Re: Virtualizing development environments in 2023

#58

Post by ElFitz »

icedchai wrote: post #30
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…

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.

Re: Virtualizing development environments in 2023

#59

Post by ohthehugemanate »

TFA goes right into the core complexity and misses it.

"Dev environment" depends on what kind of work you are doing. What a web developer needs is worlds apart from what a driver developer needs in terms of capability, resourcing, isolation, and rebuilds. Trying to offer a single environment for anyone who builds anything using a computer, is analogous to a single environment for anyone who uses a screwdriver. An electrician is using the same tool, sure, but they're doing fundamentally different work from a kitchen installer or a plumber and have vastly different needs. The single environment with all the capabilities that any computer developer needs is called a "computer."

IMO this is the genius of VSCode remotes. They built a core capability of running the bulk of the IDE "somewhere else" with just the display layer on your local machine. Then they can allow the developer to choose if container(s), VM(s), and local or remote are right for their case, without having to learn new tooling. They can even let you choose if "owning a computer" is required, or if a web browser is sufficient.

Re: Virtualizing development environments in 2023

#60

Post by victorbjorklund »

gspencley wrote: post #20
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…

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…

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.
Post reply on HN