| This is an awesome writeup of the tools and culture issues you run into maintaining dev environments. 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 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. 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`. 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. 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 (https://facebook.github.io/watchman/)
- 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 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. 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. |