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

151–160 of 235 posts

Re: Devpod: Remote development environment at Uber

#151

Post by larsla »

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…

We had SunRay at a municipality here in Sweden where I worked at the IT department. I tought it was really cool and I had built our own "session routing" script that could connect terminals to different servers based on the smartcard ID. Terminals in the schools connected to a school server where students could login without smartcards, but if a teacher inserted their card it would connect them to the "admin" server or to a windows VM.

I had my own server in the DC that I could then connect to from my desk using a multi-monitor SunRay terminal. At home I had a SunRay connecting in to the office with VPN. I could move between terminals by just inserting my smartcard in whichever terminal I was at. There was even a company creating a SunRay laptop called Gobi that I tried using , but a regular laptop with the software client was a much better experience.

Re: Devpod: Remote development environment at Uber

#153

Post by CrimsonRain »

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…

Import by path for monorepo is an anti pattern. It is exactly what another gp complained about: turning monorepo into soft dependant monolith.

https://news.ycombinator.com/item?id=34048245

Re: Devpod: Remote development environment at Uber

#154

Post by rtpg »

siliconc0w wrote: post #62

I've tried to setup this up at a small tech company pre-kubernetes and there were a lot of challenges... * low utilization, so you need to auto-shutdown or auto-scale down systems but sometimes jobs did need to run overnight or on the weekend so you needed an interface/user training to avoid upsetting users/killing their jobs. * local hardware is cheap and powerful - employees are already issued really powerful lapto…

Yeah I can't really get beyond this thing about how powerful our machines on our desk are compared to what hosting providers charge if you have 12 months utilization (I get people in SV change jobs every 6 months but).

I guess the thing that makes this make sense for Uber is the ginormous repo? This probably is a good "big ball of mud" solution to a bazillion tiny projects, each with varying degrees of documentation making it impossible to run.

One day we as an industry will figure out how to make it so that our dev setups work and run well in a multitude of environment (hopefully without that solution involving "we are pinning to a specific Ubuntu docker image"...)

Re: Devpod: Remote development environment at Uber

#155

Post by lukeramsden »

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…

I agree with the other commenter - in my view, a monorepo is the _best_ choice for a small company. I guess this depends on what tooling is available for your language / ecosystem of choice though. In my experience of TypeScript and Java with monorepos, you definitely need to know how to configure the tooling properly (which is certainly "overhead"), but it massively reduces the maintenance cost and increases the consistency of your tooling config. Spreading out over loads of repos means you need to share artefacts, which means package managers and package manager hosts, and a whole suite of release CI/CD which gets out of sync almost immediately.

It's also getting a lot better, gradle works amazingly well for a monorepo even with dozens of developers committing to it every day with shared caching, nx/turborepo/others are making the story for front-end/TS much better too.

Re: Devpod: Remote development environment at Uber

#156

Post by rtpg »

CrimsonRain wrote: post #150
ithkuil wrote: post #131

Earlier quoted context omitted.

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…

Can you explain how a monorepo for microservices is a tooling nightmare and bandwidth sink? In my experience, a monorepo significantly makes things easier and saves time everyday for all developers involved when compared with multi repo.

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 libraries that really should just be one library instead of 300 npm packages or whatever.

Re: Devpod: Remote development environment at Uber

#157

Post by rtpg »

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.

But now you're saying "we shouldn't change dependencies". Pypy turns out to work nicer than CPython? now you have a rollout project to your team. Swapping out some libraries? Another rollout project.

Now, it's great if you can avoid complex setups in general cuz complex is harder no matter what! But if you're starting from a complex setup, having easy ways to roll out changes is an important step in actually doing the simplification work to get to where you want to be!

Re: Devpod: Remote development environment at Uber

#158

Post by jsbdkdbcjcndkd »

lhorie wrote: post #75
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 monolith…

in 7 years someone will discovery a random subdirectory that doesn't build because wormholes weren't a thing back then ;)

monorepos solve none of the problems you listed. you are just basking in the short lived light after a big refactoring.

only thing monorepo does is make it easier to update some shared code and have all code which uses it run tests beforr pushing the new lib version. with many repos (micro repos is false speach to justify monorepos) you first publish the shared lib and then find out downstream failures.

anyone using monorepo in a way you can't build a small pieceocally is doing it very wrong.

Re: Devpod: Remote development environment at Uber

#159

Post by rtpg »

Groxx wrote: post #148
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…

It's much more of a political tool than a technical one. Every benefit (minus atomic commits*) can be had immediately on micro-repos with a for-loop to do the monorepo-thing in each one. If bazel is what you want, great, use bazel! In microrepos! Want consistent dependencies? Enforce them! HEAD must build? Wonderful, nothing's stopping you from doing that! It's all solvable, and quite easily. What you actually want i…

Monorepo lets me have a _single_ Github PR with the changes across 4 projects in front of me. To replicate what you're talking about in a multirepo setup, you have to introduce changesets in 4 different places, then merge them in the right order, make a bunch of tiny releases, update commit hashes to point to the right one, and do a lot of other bookkeeping because in this house we keep our projects separated.

Re: Devpod: Remote development environment at Uber

#160

Post by deng »

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…

I worked on a Sun Ray. I and many colleagues absolutely hated it.

These tiny machines were just way too slow to handle even the tiny amount of work they had to do. Also, everyone knows that X over network is just not made for modern applications ("modern" in the year 2000!). I worked with Matlab, and had a lot of fun trying to rotate 3D plots with a few thousand points. It was just unbearable.

Then of course the "single point of failure" thing. Network problems? No one can work. Main server has a drive failure? No one can work. Main server needs an upgrade? No one can work.

The Sun Rays had super-poor USB support. My ergonomic keyboard had no auto-repeat when connected to these things, absolutely impossible to fix or even debug. Then of course there was Sun software: although they invented Java, their JVM was leaking like a sieve and everything Java had to be restarted regularly. The Sun coreutils were just very limited compared to the GNU counterparts. We complained endlessly, and in the end, IT budged and we all got our dedicated Linux machines.

Post reply on HN