Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Devpod: Remote development environment at Uber

uber.com

Post reply on HN
Print view View original

101–110 of 235 posts

Re: Devpod: Remote development environment at Uber

#101

Post by jonas21 »

teeray wrote: post #90
fragmede wrote: post #76

Earlier quoted context omitted.

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.

Re: Devpod: Remote development environment at Uber

#102

Post by jahewson »

layer8 wrote: post #36
why5s wrote: post #30

Earlier quoted context omitted.

For work-related stuff: I disagree. We're not even at Uber's scale at my company and I hate having to manage the ever-changing set of dependencies that I have no control over.

The thing is, it doesn’t have to be ever-changing, and creating a reproducible working setup locally can be achieved by appropriate setup scripts.

In practice setup scripts are brittle. New person joins the team and their script fails because it turns out everyone else’s dev environment was only working due to something left behind by some older script. Hotfix requires checking out an old branch but now I need to run an old script but my setup is from the future - the old script doesn’t know what needs to be un-done to get the system to a consistent state. And what about data? My old data has gone, the data I have is from the future. Never mind simple stuff like the script author assuming node is in /usr/bin but that’s not true for me because I use nvm.

Re: Devpod: Remote development environment at Uber

#103

Post by employeedeuber »

nsenifty wrote: post #78
employeedeuber wrote: post #72

The limiting factor here is the IDE experience. You can build all this amazing architecture to provision and serve the source bits of the monorepo but if the IDE experience is janky? folks will not adopt it. The slow adoption rate speaks to that. If it truly was a productivity boom we would see a sharp spike to near 90% or more. Instead we see a slow change which is more akin to a mandate and all docs heavily suggest…

Both VS Code and IntelliJ have first class support for remote development as referenced in the article. I have been using Github codespaces for a while now and you can't nearly tell you aren't developing locally. Add to that faster builds without your laptop sounding like a jet engine.

I’m not sure what repo sizes your developing in, but at big enough numbers, the set of protobuf/thrift definitions, package dependencies, and sheer number of files being looked at, brings all the remote products to their knees. IntelliSense and other syntax, highlighting, chokes.

The biggest services/apps at Uber are not developed in devpods. Speculative, but these IDE’s were developed first as local first environments, there’s lots assumptions they make, adding up to terrible latency.

Re: Devpod: Remote development environment at Uber

#104

Post by lhorie »

voz_ wrote: post #91

This isn’t entirely honest, as Uber doesn’t have one monorepo, it has multiple. They never understood what Mono means lol.

The joke is that we love them so much that we have many of them.

In seriousness, we historically used microrepos and just getting to language-specific monorepos was already a monumental effort.

Re: Devpod: Remote development environment at Uber

#105

Post by Arelius »

tylerhou wrote: post #51
layer8 wrote: post #36

Earlier quoted context omitted.

The thing is, it doesn’t have to be ever-changing, and creating a reproducible working setup locally can be achieved by appropriate setup scripts.

Setup scripts that mutate an operating system are fragile. Break something? Unless you understand how the scripts work (which will become stupidly complex at a scale like Uber’s) you will have to reinstall your machine. Or you will have to staff a ton of support to help users when they do break their configuration. Spinning up a VM with an image containing all the development tools is a much smoother experience most…

That's a false dichotomy. Just because you don't have a VM doesn't mean that the alternative is a build environment and setup that mutates an operating system.

Re: Devpod: Remote development environment at Uber

#106

Post by layer8 »

tylerhou wrote: post #51
layer8 wrote: post #36

Earlier quoted context omitted.

The thing is, it doesn’t have to be ever-changing, and creating a reproducible working setup locally can be achieved by appropriate setup scripts.

Setup scripts that mutate an operating system are fragile. Break something? Unless you understand how the scripts work (which will become stupidly complex at a scale like Uber’s) you will have to reinstall your machine. Or you will have to staff a ton of support to help users when they do break their configuration. Spinning up a VM with an image containing all the development tools is a much smoother experience most…

Using a VM is fine. One can use it locally.

Re: Devpod: Remote development environment at Uber

#107

Post by lukewiwa »

I've definitely used the vscode remote ssh functionality before when I've had to use a particular architecture (x86) while I was developing on an M1 mac. In cases like this I already have the dev environment configuration setup for local dev so it's super easy to spin up an EC2 instance and I'm off to the races.

I definitely see the use case, but in saying that I find local development really valuable and default to it when I can. I do however run dev work almost exclusively inside a container so I'm flexible either way. I can see how some might not be.

Re: Devpod: Remote development environment at Uber

#108

Post by layer8 »

jahewson wrote: post #102
layer8 wrote: post #36

Earlier quoted context omitted.

The thing is, it doesn’t have to be ever-changing, and creating a reproducible working setup locally can be achieved by appropriate setup scripts.

In practice setup scripts are brittle. New person joins the team and their script fails because it turns out everyone else’s dev environment was only working due to something left behind by some older script. Hotfix requires checking out an old branch but now I need to run an old script but my setup is from the future - the old script doesn’t know what needs to be un-done to get the system to a consistent state. And…

I'm sorry, but this is the task of proper configuration management. Yes, don't depend on local stuff that isn't configuration-managed. Don't have a workflow where you check out an old branch in a newer environment. Of course you need a way to establish the older environment in that case. I'm assuming that Devpod does a similar thing on the server side. My point is, the ability to reproduce a working setup doesn't imply a requirement of having to work remotely.

Re: Devpod: Remote development environment at Uber

#109

Post by intelVISA »

aaomidi wrote: post #41
berkle4455 wrote: post #40

Earlier quoted context omitted.

I'm 100% the opposite side of this argument. Running your entire stack locally is a silly trend that cost us a decade of productivity. In the early to late 2000's the remote-dev approach was very common. It wasn't "push a button and you have a dev instance!" easy but it yielded similar results.

I'm slowly getting to the point of "I want my computers to be a thin client around some config files". Treat your computer like cattle, rather than a pet, etc etc.

[Obligatory Nix stanning here]

Re: Devpod: Remote development environment at Uber

#110

Post by mplanchard »

jahewson wrote: post #102
layer8 wrote: post #36

Earlier quoted context omitted.

The thing is, it doesn’t have to be ever-changing, and creating a reproducible working setup locally can be achieved by appropriate setup scripts.

In practice setup scripts are brittle. New person joins the team and their script fails because it turns out everyone else’s dev environment was only working due to something left behind by some older script. Hotfix requires checking out an old branch but now I need to run an old script but my setup is from the future - the old script doesn’t know what needs to be un-done to get the system to a consistent state. And…

We’ve had good luck using nix for this. Same dependencies for the local dev environment as for the built containers. Same config. All deterministic. And not just major deps like programming languages, but sed, bash, grep, and all the other shell tools, so no more worrying about people running scripts on mac’s ancient version of bash.
Post reply on HN