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

221–230 of 235 posts

Re: Devpod: Remote development environment at Uber

#221

Post by lhorie »

hrpnk wrote: post #178
lhorie wrote: post #75

Earlier quoted context omitted.

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

Thanks for the insights. > E.g. fixing log4j vulns is a lot easier when you can patch everything simultaneously. This is true, though the refactoring action done can also be distributed and carried out via automated Pull Request creation to multiple repos. You still will deploy the changes over a period of time with a degree of parallelism. > We had microrepos before and the main problem is that to this day I still g…

Upgrades come in a spectrum. Some are able to automerge via dependabot or similar tools, some need minor codemodding and can be managed by tools like soucegraph's new offering. Some take months of dedicated effort and digging through the ripple effects across a web of ecosystem libraries (React comes to mind).

The problem monorepos attempt to solve isn't a technology problem, it's more of a people problem. For example, say you cron CI job fails. Then what? Someone needs to look at it.

It's easier for someone to fix things they currently have context for (e.g. if I upgrade Python or update some security-related config and something breaks, I can reason it was my change that broke it), vs an unsuspecting contractor getting around to some backlog task 6 months after the fact with no context.

Organizationally, we can shard tasks to match areas of expertise. We only need one Node.js expert, one tzdata expert, one JRE expert, etc, to upgrade each of these, instead of everyone needing to obtain above average familiarity w/ obscure FFI bullshit or whatever in each technology.

Re: Devpod: Remote development environment at Uber

#222

Post by juancn »

These things usually suck when latency is high... even if you are supporting most major regions it's not usual to find yourself in a situation when you have a few hundred ms latency.

Anything over ~40ms is very noticeable when typing and editing.

Then you're screwed.

Re: Devpod: Remote development environment at Uber

#223

Post by rtpg »

dilyevsky wrote: post #214
rtpg wrote: post #156

Earlier quoted context omitted.

The biggest issue is that every CI provider speaks with "repo=project" language, so your way forward with monorepos is using stuff like Bazel. Bazel is extremely cool! But you end up with, like, a handful of people on the team who can write Bazel and eveyone else cargo culting their way through it. There are a lot of JS "monorepo management" tools but they all seem concerned about the release phase for a lot of libra…

> Bazel is extremely cool! But you end up with, like, a handful of people on the team who can write Bazel and eveyone else cargo culting their way through it. It's not that difficult and docs are outstanding. It can and it will be worse with your own Bash-isms that likely won't have any docs at all.

I think Bazel is doing a lot of good stuff... but I think it suffers a bit from the same thing as Angular, where it makes a lot of its own terminology.

There is another aspect where if you are using a language like Python or JS then you have to kind of swim upstream to get an existing project onto Bazel. Far from impossible but if you just look at the default Bazel stuff without pulling in third-party libs it's pretty tedious to get a project with a good amount of dependencies working.

Re: Devpod: Remote development environment at Uber

#224

Post by SergeAx »

And this, ladies and gentlemen, is where monorepos will inevitably take you.

There's actually an elementary litmus test on migrating to monorepos. It is a questionnaire with only one question: is your company Google? If the answer is "no" — you don't need a monorepo.

You are welcome.

Re: Devpod: Remote development environment at Uber

#225

Post by SergeAx »

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…

The rationale is that Google, Meta, Microsoft and other successfull companies are running monorepos. Ergo, if you want your company to be successfull — you have to employ monorepo too. It's that simple!

Re: Devpod: Remote development environment at Uber

#226

Post by stitched2gethr »

SergeAx wrote: post #225
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…

The rationale is that Google, Meta, Microsoft and other successfull companies are running monorepos. Ergo, if you want your company to be successfull — you have to employ monorepo too. It's that simple!

I'm not sure it is.

Some of us have evaluated several approaches based on their merits and tried to makes decisions that are best for our specific organization.

Re: Devpod: Remote development environment at Uber

#227

Post by hbrn »

ithkuil wrote: post #131
alganet wrote: post #84

Let's face it: monorepos are just huge monoliths. If you want modular software, you WILL have to pay the price of fragmentation. Someone needs to think about the boundaries between different parts of a system. If those boundaries are defined by functions, classes, packages or services, it doesn't matter that much. Yes, it is always a pain. Shipping the entire forest of modules in a single repo seems like a good compr…

Monorepos and monoliths are orthogonal Monorepos are a tooling nightmare. Monorepos are a bandwidth black hole. Monorepos make some things possible that are just not possible or very very hard when you have multiple independent repos that are built and tested independently. Namely, a) they allow you to test the effects of a change on all the components that depend on you, before you merge your change. This reduces th…

That's exactly how I understand the benefits of monorepo and it seems like a terrible idea.

You might spend one week building next version of your component and 3 months updating all of the dependents. Then do it again. And again. You are working at a fraction of your productivity. I wonder if that's why Google needs thousands of engineers.

Whereas I just updated stripe from 2.x.x to 5.x.x in one of the projects I'm working on, because new version has features that I needed. I never wasted time updating to other versions until I had a need to.

It also limits your ability to break backwards compatibility in new versions, because we all of course are coming up with great designs right from the beginning.

I get the security and performance benefits of keeping all dependencies up to date, but man, the time sink and limitations seem so not worth it.

Re: Devpod: Remote development environment at Uber

#228

Post by akvadrako »

microsoftdoes wrote: post #207
yjftsjthsd-h wrote: post #133

Earlier quoted context omitted.

It would be, if everyone agreed on a toolkit. As it as, at least X11, AFAIK Wayland, and Windows/RDP ended up just throwing pixels over the wire because every program renders text/menus/whatever differently.

RDP does not mostly do that. It sends higher level commands like text and geometry placement. That’s why it performs 10x better than the competition.

Actually it does do that, since about 2010: https://www.anandtech.com/show/3972/nvidia-gtc-2010-wrapup/3

RDP doesn't perform even 0x better than the competition, like parsec.

Re: Devpod: Remote development environment at Uber

#229

Post by voz_ »

lhorie wrote: post #104
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.

I was on the first ever team to use or setup monorepos at Uber. We even had a banner lol. In hindsight it was the right idea but a totally wrong implementation. I wish you the best but, IMO, dividing the monorepos by language is and was a mistake.

Re: Devpod: Remote development environment at Uber

#230

Post by eikenberry »

allset_ wrote: post #128
eikenberry wrote: post #92

Earlier quoted context omitted.

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.

I haven't experienced it yet, only read about it in various places. So it only exists as a future possibility for me at this point and as speculation about how the various places I've worked or know well for other reasons would use it.
Post reply on HN