This is an awesome writeup of the tools and culture issues you run into maintaining dev environments.<p>From post, the problems that justified central dev boxes are roughly:
1. dependency / config mgmt / env drift on laptops
2. collaboration / debugging between engineers
3. compute scaling + optimization
4. supporting devs with updates and infra changes<p>The last one is particularly interesting to me, because supporting the dev env is separate engineering role/task that starts small and grows into teams of engineers supporting the environment.<p>I'm helping build Flox.
We're working on these pain points by making environments (deps, vars, services, and builds) workable across all kinds of Mac/Linux laptops and servers.
1) a. Virtualize the pkg manager per-project
b. Nix packages can install across OS/arch pretty well
2) Imperative actions like `flox install`/`upgrade` always edit a declarative env manifest.toml -- share it via git
3) less Docker VM's -- get more out of devteam Macbooks
4) reduce toil with a versioned, shareable envs
--> less sending ad-hoc config and brew commands to people (as mentioned in the post.)
Just `git pull && flox activate`.<p>I think on problem point #2, collab tools are advancing to where, pairing on features, bugs, and env issues can be done without central SSH. (ex: tmate, vscode liveshare, screensharing, etc) -- however, that does sort of fall apart on laptops for async debugging of env issues (ex: when devprod is in the US, and eng is in London).
Having universal telemetry on ephemeral cloud dev-boxes with a registry and all of the other DNS and SSH goodies could be the kind of infra to aspire to as your small teams run into more big-team problems.<p>In the Stripe anecdote, adopting the centralized infra created new challenges that their devprod teams were dedicated to supporting:
- international latency from central, US-based VM's
- syncing code to the dev boxes (<a href="https://facebook.github.io/watchman/" rel="nofollow">https://facebook.github.io/watchman/</a>)
- linting, formatting, generating configs (run it locally or serverside?)
- a dev workflow CLI tool dedicated to dev-box workflows and sync'ing with watchman's clock
- IaaS, registry, config, glue for all the servers<p>This is all very non-trivial work, but maybe there's a future where people can win some portability with Flox when they are small and grow into those new challenges when it's truly needed -- now their laptop environments just get a quick `flox activate` on some new, shiny servers or Cloud IDE's.<p>I really like the notes from the author on how useing Language Server Protocol across a high latency link has great optimizations that work along side the watchman sync for real-time code editing.