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

131–140 of 235 posts

Re: Devpod: Remote development environment at Uber

#131

Post by ithkuil »

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 the noise caused by regressions (API or behaviour) introduced in one component that is depended on by many consumers.

b) they are a practical way to ensure that all components have up to date internal dependencies: by placing the burden of API and behaviour breakage to the author of the change, you don't end up having hundreds of teams each struggling to keep up with dependencies that keep breaking their builds when you update them and consequently hating the teams that release those changes.

None of these things is a big deal unless you're a huge company with hundreds of teams.

I think in theory there could be some tooling and workflow that could provide all or moat of the benefits of monorepos, without the downsides.

Until then, monorepos are likely going to be a bad choice for small companies.

Re: Devpod: Remote development environment at Uber

#133

Post by yjftsjthsd-h »

paxys wrote: post #89
akvadrako wrote: post #80

Earlier quoted context omitted.

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.

Sure but most regular consumer or business applications don't really need that level of graphical power. Rendering a menu or button or blurb of text locally from some layout language is always going to be more performant than streaming raw pixels from a server.

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.

Re: Devpod: Remote development environment at Uber

#134

Post by yjftsjthsd-h »

mhitza wrote: post #77
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?

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

> "stream" only the window

I mean, that is a thing xpra can do. Or, x11vnc can do it with some hoop-jumping.

Re: Devpod: Remote development environment at Uber

#135

Post by allset_ »

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…

> you start creating a complicated network of soft dependencies between those modules. And when you have everything in a single repository, it's hard NOT to do that.

That is what the visibility [1] in Bazel solves. You can't import other people's code unless they say you can by making their code visible to yours.

[1] https://bazel.build/concepts/visibility

Re: Devpod: Remote development environment at Uber

#136

Post by yjftsjthsd-h »

sierkov wrote: post #132

> The Linux file system, which performs better compared to laptop file systems ... say what?

Probably means "our laptops only run Windows, which infamously has performance issues with git because of different filesystem semantics (something about caching metadata?), but Linux filesystem drivers don't have that problem".

Re: Devpod: Remote development environment at Uber

#137

Post by eloisius »

lopkeny12ko wrote: post #61
EastSmith wrote: post #24

We are moving to such cloud environment, and it makes me sick. Maybe you need to dockerise Mongo, MySql and 5 other dependencies - I can get this, but I don't get it why the rest the code should still be running in the cloud. Python, Rails, Node? Why? Developers should be able to run 1 shell commands to install node. Dev experience excuses are just excuses for a bad setup. So, fix your setup, please. Not being able t…

Same here. We have a similar setup as described in this article. But they also issued me a 16-core workstation with 64 GB of RAM! Like just let me use my hardware goddammit.

In a large org those local resources are allocated for running Tanium.

Re: Devpod: Remote development environment at Uber

#138

Post by decodebytes »

This just seems like a lot of cloud costs to take on, considering how much power developers laptops carry and would be completely untapped. Instead of having everything remote, to me it appears more sensible to have a distributed development environment. I guess this would look something like the dagger.io folks are shooting for.

Re: Devpod: Remote development environment at Uber

#139

Post by eloisius »

unity1001 wrote: post #124
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…

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

That time is spread randomly over thousands of devs and not lost all at once during a sev1

Re: Devpod: Remote development environment at Uber

#140

Post by yjftsjthsd-h »

decodebytes wrote: post #138

This just seems like a lot of cloud costs to take on, considering how much power developers laptops carry and would be completely untapped. Instead of having everything remote, to me it appears more sensible to have a distributed development environment. I guess this would look something like the dagger.io folks are shooting for.

I think the steelman answer is that if this works well, you don't give developers powerful laptops; you give them cheap laptops that are little more than dumb terminals. (Whether that works is left as an exercise for the reader.)
Post reply on HN