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

71–80 of 235 posts

Re: Devpod: Remote development environment at Uber

#71

Post by teeray »

charcircuit wrote: post #23
teeray wrote: 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…

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.

Re: Devpod: Remote development environment at Uber

#72

Post by employeedeuber »

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 suggesting for folks to use it.

Re: Devpod: Remote development environment at Uber

#73

Post by Galanwe »

nsm wrote: post #65
whydid wrote: post #59

Earlier quoted context omitted.

How many people are in your organization?

People seem to conflate a monorepo with having everything else the same as well, just because that's how Google and other BigCos do it. You don't have to. At some level a monorepo is just a way to stick all your code in one giant directory and manage it all under one VCS repository. You could still do separate build tools per project, separate vendoring if you really wanted and so on. However you may find that being…

> However you may find that being able to simply import other first party code by path instead of doing some cross repo dependency process is a massive win.

I don't quite get the benefits of "depending by path".

The engineering seems huge, you now have to create a magic meta build and testing system so that only individual components that changed are rebuilt/tested. That seems like a scaling nightmare at best.

Also, dependency management is hardly an issue on most modern stacks anyway. Javascript, rust, python, etc, all have private package hosting tools that are trivial to deploy.

Re: Devpod: Remote development environment at Uber

#74

Post by sk0g »

nitwit005 wrote: post #69

I guess they expect Uber devs to get an extra day or two off annually from their cloud provider being down: > Unfortunately, here we are limited by the cloud provider availability that’s capped at 99.5%.

That's a big improvement over maintaining non-trivial local environments at least.

Re: Devpod: Remote development environment at Uber

#75

Post by lhorie »

Galanwe wrote: post #56

Can someone explain the rationale behind switching to a monorepo? I just don't get it. Does it mean also having a single unified production environment build? I have been managing a stack composed of 500+ repositories, communicating through webservices, files and ABIs for many years now, and never quite hit much of the issues cited as reasons to switch to monorepos. Having multiple small independent environments for…

I maintain the web monorepo at Uber, so I think I can give some context.

Monorepos allows us to centralize important dependency upgrades. E.g. fixing log4j vulns is a lot easier when you can patch everything simultaneously. Same for tzdata (2022g gave very little heads up) Auditing for npm supply chain attacks was a lot simpler in monorepo than microrepos. Etc.

Monolithic version control doesn't have to mean monolithic everything.

Our web projects can be deployed independently of each other, and we leverage tool like yarn workspace focus and bazel for granular installs and builds/tests/etc.

It doesn't have to mean monoversions either. We support multiple version of libraries, though we prefer coalescing them as much as possible to facilitate effort centralization. Finding out that your library change will break downstreams before you land the change is a feature.

We had microrepos before and the main problem is that to this day I still get some random team coming to me for help w/ some rediscovered 7 year old repo that doesn't even build anymore cus lockfiles weren't a thing back then.

At a large enough org, you'll inevitably see the full spectrum of team quality, from the really good teams to the one intern/contractor getting thrown into the deep end of some unloved ancient thing. You want a common denominator that lets you do things like patch vulns in unstaffed projects.

I've done fairly large migrations both to and from monorepos. Each has pros and cons. For us and companies like Google, monorepos work well with our organization model. For others it may not.

Re: Devpod: Remote development environment at Uber

#76

Post by fragmede »

teeray wrote: post #71
charcircuit wrote: post #23

Earlier quoted context omitted.

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

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.

Re: Devpod: Remote development environment at Uber

#77

Post by mhitza »

jimmaswell wrote: post #44
gandalfgeek wrote: post #22

Back in the early 2000s, Sun ("the network is the computer") had a similar solution that worked seamlessly for most of their software org-- the Sun Ray. https://en.wikipedia.org/wiki/Sun_Ray It was a network terminal. Your files and entire session were on the server. Your “local” terminal consisted only of a network interface and enough compute power to display your session. The way they had it set up was that you co…

What's old is new again. How soon until we realize the X window system actually had some good ideas again and start running desktop apps on cloud servers for remote work?

I bet on LAN X11 forwarding was pretty sweet, but when I tried it over Wi-Fi/tethering is was pretty janky (and before someone suggests xpra, that wasn't buttery smooth either). But I do like the idea of what X11 forwarding is, better than VNC where whole desktop is shared. I read that on Windows RDP can "stream" only the window, whereas on Linux the implementation is full desktop only? (please correct me if I'm wrong cause I would love to tunnel apps from servers).

Re: Devpod: Remote development environment at Uber

#78

Post by nsenifty »

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.

Re: Devpod: Remote development environment at Uber

#79

Post by dariusj18 »

gandalfgeek wrote: post #22

Back in the early 2000s, Sun ("the network is the computer") had a similar solution that worked seamlessly for most of their software org-- the Sun Ray. https://en.wikipedia.org/wiki/Sun_Ray It was a network terminal. Your files and entire session were on the server. Your “local” terminal consisted only of a network interface and enough compute power to display your session. The way they had it set up was that you co…

The thin terminal possibilities that Java was working on solving was exciting back in the day.

Re: Devpod: Remote development environment at Uber

#80

Post by akvadrako »

paxys wrote: post #48
jimmaswell wrote: post #44

Earlier quoted context omitted.

What's old is new again. How soon until we realize the X window system actually had some good ideas again and start running desktop apps on cloud servers for remote work?

It had some good ideas, but that was the extent of it. Every iteration of the solution since then has agreed that streaming all application UI is always going to be janky and needless. It's a lot better to host the data on the server side and let the client handle visual rendering by itself.

These days lots of people stream games and CAD sessions over the internet using software like parsec. It works quite well and is often better than the UI running locally on an underpowered GPU.
Post reply on HN