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

141–150 of 235 posts

Re: Devpod: Remote development environment at Uber

#141

Post by nathants »

using remote resources as a part of your local dev flow can be very useful if your local environment is constrained on cpu/ram/gpu/ssd/bandwidth.

this can be as simple as an ephemeral ec2 spot machine that reacts every time files on it’s filesystem change. it then does stuff, like building and shipping.

your local setup needs to rsync files from local to remote every time you save a file.

i’m on an upload constrained setup right now, and this[1] significantly speeds up my iterations uploading lambda zips.

fancier setups probably are similarly advantageous, but add tradeoffs proportional to their complexity.

1. https://github.com/nathants/aws-gocljs/blob/258ea5bb72d06a50...

Re: Devpod: Remote development environment at Uber

#142

Post by grogenaut »

paxys wrote: post #113
jimmaswell wrote: post #87

Earlier quoted context omitted.

I heard Stadia was actually pretty good, especially for a game that wasn't super sensitive to fast reactions like RDR2.

The tech was by most accounts groundbreaking. The problem was with everything else – business model, pricing, games, customer trust.

It wasn't really groundbreaking tech. It's been possible for years, see online. It's just the business model sucks. We did some prototypes in a large company I worked for and it was easy to tell if you could put servers in local data centers with fat pipes it would work. We had demos using ec2 back in 2013. Them we ran the numbers and were like why, esp with free to play becoming more and more of a thing so we canned it.

Nvidia had a successful product as well before stadia. Hell I remember reading a use AWS GPU instances as a gaming machine blog posts before stadia.

Re: Devpod: Remote development environment at Uber

#143

Post by yjftsjthsd-h »

lhorie wrote: post #114
layer8 wrote: 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…

> 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

Okay, but if you can define/script your environment enough to run in a pod, couldn't you just run that locally? You already have to solve the manual steps either way...

Re: Devpod: Remote development environment at Uber

#144

Post by fragmede »

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

> at Uber scale it is what 64 GB RAM ?

I don't work there, but I bet their full stack takes more than 64 GiB RAM.

> trivially this is a docker compose stack right ?

In the way that docker is the same thing as Kubernetes, yes. However there are differences that become material when you zoom in a bit closer.

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.

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

I don't think it's an optimization for dev laptop specs. At the end of the day, it's cheap for Uber to just max out the ram on dev laptops.

Re: Devpod: Remote development environment at Uber

#145

Post by unity1001 »

eloisius wrote: post #139
unity1001 wrote: post #124

Earlier quoted context omitted.

> 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

That time is spread randomly over thousands of devs and each of them encounter similar package dependency issues every other day. Its not 1 in 1000 devs every day. Everyone will need to solve it locally themselves.

Re: Devpod: Remote development environment at Uber

#146

Post by eikenberry »

spicybright wrote: post #117
eikenberry wrote: post #112

Earlier quoted context omitted.

Problem is with people who put together these sorts of systems tend to think theirs is best and everyone should use it. For example I once interviewed at a place where every developer got an identical Mac with the dev environment already setup and you couldn't use something else as they thought it better if everyone had the same setup to enable easier pairing. I could really see something similar happening with these…

Setting up a working dev environment can take days to a week+ in my experience. On boarding can take a while, so getting a VM image or whatever that works out of the box that you can build on is a really good thing. It's great too because if your own environment breaks, you can compare to a working one to fix it. Just because a company might abuse it doesn't mean we should avoid it.

I have no problem with the idea of having a pre-existing image to kick off your dev setup. Just more that, human nature being what it is, it is unlikely to stop there. It will vary from company to company of course and I think my current company would adopt it in a good way but I also can think of one or two previous employers who would politicize and abuse the idea.

IE. it's no slam dunk. Like any other tool of this sort is will be used for good and ill.

Re: Devpod: Remote development environment at Uber

#147

Post by pxc »

intelVISA wrote: post #109
aaomidi wrote: post #41

Earlier quoted context omitted.

I'm slowly getting to the point of "I want my computers to be a thin client around some config files". Treat your computer like cattle, rather than a pet, etc etc.

[Obligatory Nix stanning here]

oblig. advice to wipe / on every boot: https://grahamc.com/blog/erase-your-darlings

Re: Devpod: Remote development environment at Uber

#148

Post by Groxx »

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 is reliability and consistency. A monorepo gives you one political entity, with a clear adoption path, to argue with when enforcing those kinds of requirements. So they're much more likely to actually be achieved. In a big company, that may be worthwhile... but oh boy are the downsides large, and the only way to deal with them is massive eng effort and money.

* Atomic commits are a completely false promise. Your code on multiple machines doesn't change execution atomically, and being able to split a breaking change is a good thing, and massively harder to support in monorepos - it lets you adopt changes gradually, rather than forcing it on everything at once. You know, the same thing that every safe-change-practice handbook says you should do. Except in monorepos apparently.

Re: Devpod: Remote development environment at Uber

#149

Post by ccouzens »

yjftsjthsd-h wrote: post #136
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".

Or they were using Docker on Mac

Re: Devpod: Remote development environment at Uber

#150

Post by CrimsonRain »

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…

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.

Post reply on HN