Gitpod, just use Gitpod. You can even run docker inside there.
Virtualizing development environments in 2023
21–30 of 76 posts
Re: Virtualizing development environments in 2023
#22Eh, might as well use the crazy power of that MacBook you're provisioning for each engineer.
Re: Virtualizing development environments in 2023
#23Author doesn’t mention it but I wonder if tried or considered Nix/NixOS’s reproducible developer environments and ruled them out for any reason. I couldn’t tell from the article if there’s something unique to his requirements that disqualifies them. https://nixos.org/explore https://nix.dev/
Nix solves a different problem than Hocus. Nix lets you define a development environment, Hocus gives you a way to run it on a remote server. Right now we use Dockerfiles to let users define the packages they need in their dev env, but we would like to support Nix in the future too. Interestingly, you can use custom BuildKit syntax https://docs.docker.com/build/dockerfile/frontend/ to build Nix environments with Dock…
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
Re: Virtualizing development environments in 2023
#24Earlier 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…
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 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)
Re: Virtualizing development environments in 2023
#25Earlier quoted context omitted.
Nix solves a different problem than Hocus. Nix lets you define a development environment, Hocus gives you a way to run it on a remote server. Right now we use Dockerfiles to let users define the packages they need in their dev env, but we would like to support Nix in the future too. Interestingly, you can use custom BuildKit syntax https://docs.docker.com/build/dockerfile/frontend/ to build Nix environments with Dock…
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.
Re: Virtualizing development environments in 2023
#26Gitpod, just use Gitpod. You can even run docker inside there.
yea, great for small projects but no good when you're trying to expand into enterprise capabilities -- I have to get one tool for dev, have that config diverge from CI, and then from staging
then i have to hire a large devops team to manage it all -- super inefficient
Re: Virtualizing development environments in 2023
#27I 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.
Re: Virtualizing development environments in 2023
#28Consider 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.
Re: Virtualizing development environments in 2023
#29I 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.
Docker Compose with .env overrides is very close to an ideal local dev environment, the only downside is if you don't use Linux you can hit some I/O bottlenecks (it got better with VirtioFS in Docker Desktop but still not native-speed)..
I still wait for properly usable remote work environment that trumps local in performance and convenience.... I feel like the VS Code approach with server-client IDE architecture and the client running as a web application is going in the right direction but not quite there yet.., Especially if you can leverage lots of RAM and GPU power in your workflow and often work from different locations, don't want to carry your laptop around but still want to use the same power, environment & configuration on any machine you work from....
Re: Virtualizing development environments in 2023
#30Earlier 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…
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