Every service has the risk of introducing a new point of failure, of course.

But compare dev productivity lost due to service downtime with that of each new SWE in your org burning time to A) setup their own unique snowflake of an environment and B) futzing and debugging it when it breaks or there's a software update.

> burning time to setup their own unique snowflake of an environment

Anyone good is doing that even if you tell him not to. One size does not fit all.

You already have the same concern with source control, code review, continuous integration, continuous deployment, etc.

Dev servers are arguably much simpler to provide without issues.

But I don’t really have those concerns—they’re better mitigated. If source control goes down, I have a complete clone on my machine and so do my coworkers (yay git). I have done code reviews by pasting `git am` formatted patches between coworkers during particularly long GitHub outages. CI/CD is more problematic, but I only need those things to integrate work. I can still do work and verify correctness with tests that I can run locally.

None of that is possible in a centrally-managed dev VM setup. When the VMs go down, you send your dev team home until it’s fixed. You’re still paying their salaries while you pay another team to make them productive again.

Depends on the scale you're working with. If your complete code can fit locally, you're working at a different scale. Huge monorepos won't fit on a laptop-sized local disk these days, and a full local dev env would take a half dozen VMs to even replicate half-successfully.

We’re talking generally here about all software development, so of course we can find exceptional cases to refute anything anyone says. Let’s scope the discussion to what is likely a common developer scenario where `git clone` works and it’s possible to run a reasonable facsimile of the application locally (maybe with some simulators for cloud services).

The article we're discussing is from Uber, which has a huge monorepo. It's exactly the use case they designed Devpod for.

> Huge monorepos won't fit on a laptop-sized local disk these days

Reason 743 why monorepos create more problems than they solve

Nothing is stopping developers from running the docker image locally.

Not sure what's done at Uber but I imagine HA is a requirement.

There are mitigations and a couple of hours of dev downtime is imo not the end of world. Sure, prod incident could overlap with a devpod incident but sounds like they still have the choice to do local dev.

*> higher SLA targets than production

Lost revenue is usually more impactful than the occasional lost developer time.

> All good until you have an outage

Better to have hundreds, or * gasp * thousands of engineers having to fix local package dependency problems on their computers every other day. Much better than those engineers having to keep that gigantic context loaded in their mind so that they fix those local problems.

That effort spent for maintaining local environments and navigating the package management hell is effort not being spent on creating actual code.

That time is spread randomly over thousands of devs and not lost all at once during a sev1

That time is spread randomly over thousands of devs and each of them encounter similar package dependency issues every other day. Its not 1 in 1000 devs every day. Everyone will need to solve it locally themselves.