Live data from Hacker News

Devpod: Remote development environment at Uber

uber.com

121–130 of 235 posts

Re: Devpod: Remote development environment at Uber

#121
post #35

Earlier quoted context omitted.

> Why? Three reasons from my perspective: 1) There's no setup steps. You just open your editor of choice and everything is set up for you. All the build tools, linters, specific versions of software $XYZ, etc. 2) Large VM (16 core, 96GB of RAM in my case) speeds builds and tests up dramatically. 3) Zero productivity lost if your laptop breaks. Just grab a new one from IT and you're up and running exactly where you le…

I don't see #1 happening. There is no way anyone has my personally customized development setup in some VM ready to use. More likely it is going to be one common setup that they want everyone to use.

> my personally customized development setup

Why would your personally customized development setup even need to be on the remote host? You pop up your IDE, connect to the remote host via SSH and you are set.

Re: Devpod: Remote development environment at Uber

#122
post #36
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.

> it doesn’t have to be ever-changing

It IS ever-changing. One library among the zillions of local dependencies that you need to build something changes, and you have to go through the dependency hell.

If entire software world valued backwards compatibility and vigilantly guarded it, that wouldnt be a problem. But in the package hell that we are living in today, every other day a package update brings some incompatibility or breaking change for this or that other thing.

Re: Devpod: Remote development environment at Uber

#123
post #108

Earlier quoted context omitted.

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 imp…

> I'm assuming that Devpod does a similar thing on the server side

That's why they use devpods. You moved entire configuration to the cloud. There is absolutely no reason why it should be run in your local environment.

Re: Devpod: Remote development environment at Uber

#124
post #15

This sounds great. Certainly the IP zealots love it because the code never leaves the walled garden, and it’s a super-secure blah blah environment. Consistent tooling, easy onboarding… you get the idea. All good until you have an outage. Then your development team’s productivity drops to exactly zero while you fix it and your entire production environment is now potentially vulnerable to defects you can’t fix until t…

> 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.

Re: Devpod: Remote development environment at Uber

#125

I like this workflow, use something like mutagen to sync from your local environment to the remote machine. For me, I prefer jetbrains IDEs so I tried using jetbrains gateway, it’s really buggy and slow. I prefer to use jetbrains ides on my local machine and use VSCode remote for interacting with the remote machine. I wonder though, is it worth it to setup a remote dev machine if you have an M1 Mac? I think you can g…

I think there are still some limits applied even on cutting edge hardware. GitHub previously said they hit network limitations cloning their multi-gb repo for instance.

Re: Devpod: Remote development environment at Uber

#126
post #114
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.

One of the reasons we developed devpods was because our setup scripts were unmanageable. Instructions to new employees would say things like "run this thing, scroll up past dozens of pages of stdout noise and manually deal w/ the errors buried therein by looking up relevant FAQs in some doc somewhere" The scripts would touch every technology imaginable, from brew to npm to arc (phabricator's cli) to proprietary tools…

Long before devpods (circa 2014) we had boxer, which was a command line tool that abstracted away the nitty gritty details of setting up a dev environment by orchestrating calls to AWS, vagrant, puppet, rsync, etc for you. However this was also a time when there were only a handful of services you would need to run, and because remote editing tools at the time weren’t as nice as they are now, it only worked really well if your preferred editor was vim/emacs so you didn’t have to deal with the (occasionally buggy) remote file syncing.

The devpod flow is a lot smoother. I had my laptop replaced recently and was up it running again in an amount of time that felt like cheating.

Re: Devpod: Remote development environment at Uber

#127
post #20

Earlier quoted context omitted.

It was probably just a RDP connection, which either signals how old this insight is, or how far behind Uber is on these new ways to remotely code.

The post clearly shows they're not using RDP. That said Projector round tripped all the key strokes to get new draw commands (unlike VSCode) which also results in lag. The new IntelliJ remote architecture is much better, and it seems Uber is moving that way too.

What's the new way? JetBrains Gateway? Have they caught up to VSCode's devcontainers?

Re: Devpod: Remote development environment at Uber

#128
post #35

Earlier quoted context omitted.

> Why? Three reasons from my perspective: 1) There's no setup steps. You just open your editor of choice and everything is set up for you. All the build tools, linters, specific versions of software $XYZ, etc. 2) Large VM (16 core, 96GB of RAM in my case) speeds builds and tests up dramatically. 3) Zero productivity lost if your laptop breaks. Just grab a new one from IT and you're up and running exactly where you le…

I don't see #1 happening. There is no way anyone has my personally customized development setup in some VM ready to use. More likely it is going to be one common setup that they want everyone to use.

Why are you speaking as if this is some weird future state that doesn't exist and has lots of unknown downsides? This is the current state in some companies. I work in this flow daily and really appreciate the value it delivers.

Re: Devpod: Remote development environment at Uber

#129

Earlier quoted context omitted.

Any externally visible docs on it? Google's is documented at https://cloud.google.com/blog/topics/developers-practitioner...

I don't think it's been discussed externally yet. It's called on-demand (some references to it here - https://developers.facebook.com/blog/post/2022/11/15/meta-de... ).

Fascinating, thanks!

Re: Devpod: Remote development environment at Uber

#130
genuine question here. im hoping u folks have put a lot more thought into it than i have.

so devpod "production OS" - the top level devpod - contains ALL running services ? at Uber scale it is what 64 GB RAM ?

if ur already using kubernetes ... why do it this way rather than have kubernetes namespaces with many containers in a dev cluster ? trivially this is a docker compose stack right ?

second question - has there been a ROI recovery in terms of laptop hardware for devs ? like - u only 8 GB ram laptops and not more.

Post reply on HN