Latency Issues with Centralized Infrastructure

“Stripe's Monorepo Developer Environment 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 &#x2F; config mgmt &#x2F; env drift on laptops 2. collaboration &#x2F; 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&#x2F;task that starts small and grows into teams of engineers supporting the environment.<p>I&#x27;m helping build Flox. We&#x27;re working on these pain points by making environments (deps, vars, services, and builds) workable across all kinds of Mac&#x2F;Linux laptops and servers. 1) a. Virtualize the pkg manager per-project b. Nix packages can install across OS&#x2F;arch pretty well 2) Imperative actions like `flox install`&#x2F;`upgrade` always edit a declarative env manifest.toml -- share it via git 3) less Docker VM&#x27;s -- get more out of devteam Macbooks 4) reduce toil with a versioned, shareable envs --&gt; less sending ad-hoc config and brew commands to people (as mentioned in the post.) Just `git pull &amp;&amp; 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&#x27;s - syncing code to the dev boxes (<a href="https:&#x2F;&#x2F;facebook.github.io&#x2F;watchman&#x2F;" rel="nofollow">https:&#x2F;&#x2F;facebook.github.io&#x2F;watchman&#x2F;</a>) - linting, formatting, generating configs (run it locally or serverside?) - a dev workflow CLI tool dedicated to dev-box workflows and sync&#x27;ing with watchman&#x27;s clock - IaaS, registry, config, glue for all the servers<p>This is all very non-trivial work, but maybe there&#x27;s a future where people can win some portability with Flox when they are small and grow into those new challenges when it&#x27;s truly needed -- now their laptop environments just get a quick `flox activate` on some new, shiny servers or Cloud IDE&#x27;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.”