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

31–40 of 76 posts

Re: Virtualizing development environments in 2023

#31

Post by black3r »

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 laptop than a $4000 laptop...

Re: Virtualizing development environments in 2023

#32

Post by fragmede »

debosmit wrote: post #24
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…

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.

Re: Virtualizing development environments in 2023

#33

Post by CGamesPlay »

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.

Re: Virtualizing development environments in 2023

#34

Post by fragmede »

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…

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.

Re: Virtualizing development environments in 2023

#35

Post by swozey »

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.

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 service or run it not as pid1 (init container or supervisord) so it can restart without killing the container but that depends on the work being done.

I'm trying to find a good example to show you but I'm not finding much. If you have a medium account this might be decent, I don't have one but it starts off going through the process https://medium.com/swlh/tutorial-how-to-use-docker-volumes-t...

With that said I use literally the exact same containers that are pushed to production.

Re: Virtualizing development environments in 2023

#36

Post by fragmede »

suryao wrote: post #25
debosmit wrote: post #23

Earlier quoted context omitted.

see this is the problem w/ all these devtools - i need to pair together 5 different things when i just want a reproducible, ephemeral environment someone needs to bring a heroku-like experience but for cloud-native development

That's the mission we're on at Argonaut. I'd love to know more about how you think about it if you're up for a chat.

What are you trying to offer above and beyond GitHub codespaces?

Re: Virtualizing development environments in 2023

#37

Post by justsomehnguy »

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…

> Virtualization means images

No. Some prefer image based provisioning, but it doesn't mean you can't have your 'own' machine.

Re: Virtualizing development environments in 2023

#38

Post by ransackdev »

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?

Not to mention the popular virtualization platforms like kvm, vmware, and hyper-v all support ballooning[1][2] where you can define a base amount of memory and a max, and when the guest garbage collects its heap within the vm the memory is reclaimed by the hypervisor.

This also allows overcommitting to better utilize the resources that would otherwise site mostly idle, and trust me every cloud provider overcommits their hypervisors, I used to work for a major one but anyone can check the cpu steal time in top and see how thrashed their host is

1. https://www.linux-kvm.org/page/Projects/auto-ballooning

2. https://pve.proxmox.com/wiki/Dynamic_Memory_Management#Ballo...

Re: Virtualizing development environments in 2023

#39

Post by stephenr »

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…

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

Re: Virtualizing development environments in 2023

#40

Post by stephenr »

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…

> 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?

Post reply on HN