[HN Gopher] Virtualizing development environments in 2023
___________________________________________________________________
Virtualizing development environments in 2023
Author : hugodutka
Score : 74 points
Date : 2023-08-04 15:28 UTC (7 hours ago)
(HTM) web link (hocus.dev)
(TXT) w3m dump (hocus.dev)
| pphysch wrote:
| This blog doesn't convince me why I should care about Hocus over
| solutions like VSCode devcontainer + Vagrant. That is more what
| it is competing with, not raw Docker/VM.
| [deleted]
| hugodutka wrote:
| Oh yes, in this post I was not trying to. Hocus gives you a web
| interface that lets you spin up a dev env with a single click
| of a button. We also implemented a git-integrated CI system
| that prebuilds your dev env on new commits. It's basically a
| self-hosted Gitpod or GitHub Codespaces.
| foxbyte wrote:
| 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.
| seabrookmx wrote:
| I don't know if I'd use the word "mature" (Docker is quite
| mature after all), but as a long-time Docker user I did jump
| into lxc/lxd and can confidently say it's "system container"
| approach is better for dev environments.
|
| I used to use WSL 2 or a VM, but on a Linux host LXD is a
| really nice workflow. I can create a fully isolated Linux
| instance with all my dev tooling on it (optionally
| script/automate the install of all my tools), and with nested
| containers enabled I can even run _Docker in that LXD
| container_ so that when I type `docker ps` on that instance,
| and `docker ps` on my host, they each have their own set of
| containers running. For example, I have an ElasticSearch and
| Redis instance running in the dev box but Syncthing on the
| host.
|
| Then I can use snapshots to back up the dev environment, or
| blow it away completely once it gathers too much cruft all
| without affecting my host. It's really great.
|
| Pair it with VS Code remote SSH and you have a very feature
| rich setup with little effort.
| m463 wrote:
| 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.
| siliconc0w wrote:
| Eh, might as well use the crazy power of that MacBook you're
| provisioning for each engineer.
| SkyMarshal wrote:
| Author 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/
| hugodutka wrote:
| 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 Docker https://github.com/reproducible-
| containers/buildkit-nix, and that's probably what we will end
| up supporting.
| midchildan wrote:
| I think Nix is relevant here, because being able to run
| software across different machines reproducibly is one of its
| major selling point. I particularly like that it doesn't rely
| on virtualization or containerization to do that. It's up to
| the user to decide how to isolate the runtime environment
| from the host or whether they even should. Alternatively,
| tools building upon Nix can make that decision for them.
| Either way, it allows for a more flexible approach when you
| have to weigh the pros and cons of different isolation
| strategies. Development environments defined by Nix tend to
| compose well too, as a result of this design.
| debosmit wrote:
| 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
| suryao wrote:
| 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.
| Nezteb wrote:
| From what I can tell, devenv [1] and devbox [2] (both built
| on Nix) can also deploy to remote servers.
|
| [1] https://devenv.sh
|
| [2] https://www.jetpack.io/devbox
| pxc wrote:
| There are a lot of other ways to deploy to remote servers
| with Nix. Many of them are NixOS-based, but some don't
| require NixOS at all.
|
| Whatever way you're using Nix for developer environments,
| you can reuse most of that work to define a package
| suitable for remote deployment.
| nickstinemates wrote:
| I am curious how important 100GB dev environment support and
| efficiently binpacking dev environments and rat-holing on memory
| efficiency actually matters for the first X enterprise customers
| for Hocus.
|
| Memory and CPU cores are cheap. Getting the UX, resource
| allocation/sizing/instance type, and general pattern for multi-
| tenant dev boxes seems more fruitful.
|
| Would love to see any data supporting this prioritization, and
| what the answer is for Workstation / HEDT-type environments given
| the industry's current focus on AI.
| stephenr wrote:
| 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 software they want inside their
| own workspaces without impacting each other.
|
| What does that even mean?
|
| Is this about someone working on a feature branch that uses some
| new dependency that needs to be installed?
|
| That's 100% the sort of thing your _local_ development
| environment is for, until you 're ready to push it to your hosted
| test/whatever environment.
|
| > But when it's running in a VM, the VM gobbles up as much memory
| as it can and, by itself, shows no inclination to give it back.
|
| Someone, anyone, tell me which hypervisor _doesn 't_ enforce a
| memory limit on VMs?
| black3r wrote:
| 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...
| Terretta wrote:
| 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
| scarmig wrote:
| 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 are easily
| provisioned and deprovisioned.
| gspencley wrote:
| 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
| environment during the interview process. If they mandate Mac
| or Visual Studio I'm not interested (not trying to start a
| flame war, those are my personal preferences). I know that
| certain organizations need their control for auditing,
| security and remote wipe reasons, and that is understandable.
| I'll just go work elsewhere. It's fine.
| debosmit wrote:
| 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)
| fragmede wrote:
| * * *
| icedchai wrote:
| 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
| easton wrote:
| > Many cloud providers, like AWS inside VM-based EC2 instances,
| won't let you run a VM since they don't support nested
| virtualization
|
| Does anyone know if there's a technical limitation to nested virt
| on EC2 or if it's just so people use .metal? I know Azure
| recently (1-2 years?) started offering it.
| colinchartier wrote:
| Nested virt doesn't work with some things like OS
| snapshot/restore, so they might not support it to allow those
| features.
| segfaltnh wrote:
| I can't imagine amazon prefers the use of metal vs. non-metal.
| As I understand the pricing they're equivalent.
| therealmarv wrote:
| Gitpod, just use Gitpod. You can even run docker inside there.
| debosmit wrote:
| 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
| swozey wrote:
| 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.
| black3r wrote:
| 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....
| CGamesPlay wrote:
| 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.
| ravenstine wrote:
| 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
| development environment. It can be a very good thing, actually,
| but you don't need containers. A development environment, in my
| opinion, should be well organized, easy for a new developer to
| pick up, but also scrappy and adaptable to new and interesting
| situations. Containers, at least in their current conception, are
| antithetical to this. They're best kept to deployments or running
| things in a scenario where you know for sure you're not going to
| tinker with anything. I don't think I've worked on a software
| project where, at some point or another, I didn't need to reach
| under the hood in some unconventional way to investigate an issue
| or simulate some circumstance. Yes, you can do those things with
| containers, but now you have to deal with that complexity, which
| can get in the way by merely being confusing and indirect.
|
| Having given up on using containers for development, when I want
| to use virtualization, I just spin up minimalist instances of
| Debian under Qemu (using the UTM GUI). This way, I can run a
| Thing (TM) in isolation, easily open up a shell, or SSH into it
| from the host shell, or start a GUI from within it if I need to,
| or install however many services I want within it and open up
| ports to the host, or have shared folders, etc. etc. etc.
|
| But what if I need multiple of a Thing (TM) running at the same
| time? In that case, I just clone the VM. No Dockerfiles, no
| docker-compose.yml, no "volumes", no orchestration, no images
| failing to build because reasons, no qcow2 files blowing up with
| Docker For Mac (though that situation has improved), no pruning
| of orphaned containers/images, no worrying about whether your
| container should only be running a single process/service, and so
| on.
|
| The only drawback to this is that, if the host is Linux, then
| it's indeed kinda dumb to be running other Linux kernels in VMs.
| But hey, it's 2023 and the difference in performance may not be
| meaningful depending on what you're doing. I know that, on an M1
| Mac, I can run graphical applications at monitor resolution with
| incredible speed (perhaps moreso with Parallels instead of Qemu),
| so I'd struggle to care about any performance drawback if my host
| was Linux on the same hardware.
|
| I'm sure that, for some, containers in development will be
| totally worthwhile. But if they don't seem worthwhile to you,
| dear reader, then that's probably because they wouldn't be.
___________________________________________________________________
(page generated 2023-08-04 23:01 UTC)