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

21–30 of 235 posts

Re: Devpod: Remote development environment at Uber

#21

Post by gandalfgeek »

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…

Every service has the risk of introducing a new point of failure, of course.

But compare dev productivity lost due to service downtime with that of each new SWE in your org burning time to A) setup their own unique snowflake of an environment and B) futzing and debugging it when it breaks or there's a software update.

Re: Devpod: Remote development environment at Uber

#22

Post by gandalfgeek »

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 could insert your Sun employee ID – the same card used to get into the building – into a slot in the terminal. That authenticated you to the server and displayed your session instantly. Want to show a colleague something you’re working on? Just put your ID into their Sun Ray and show them exactly what you were doing. That was cool! It was a frictionless way to demo and collaborate.

Re: Devpod: Remote development environment at Uber

#23

Post by charcircuit »

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.

Re: Devpod: Remote development environment at Uber

#24

Post by EastSmith »

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 to run the project natively is big red flag for me and when I move jobs will be my 1st question.

Re: Devpod: Remote development environment at Uber

#25

Post by faizshah »

I like this workflow, use something like mutagen to sync from your local environment to the remote machine. For me, I prefer jetbrains IDEs so I tried using jetbrains gateway, it’s really buggy and slow. I prefer to use jetbrains ides on my local machine and use VSCode remote for interacting with the remote machine.

I wonder though, is it worth it to setup a remote dev machine if you have an M1 Mac?

I think you can get good compile times for Rust etc. on an M1. For me I have an intel Mac at work and at home so the remote dev env is better for builds.

Re: Devpod: Remote development environment at Uber

#26

Post by cyc116 »

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…

Not sure what's done at Uber but I imagine HA is a requirement.

There are mitigations and a couple of hours of dev downtime is imo not the end of world. Sure, prod incident could overlap with a devpod incident but sounds like they still have the choice to do local dev.

Re: Devpod: Remote development environment at Uber

#27

Post by jeffbee »

xnx wrote: post #12

Similar setup at Google: https://cloud.google.com/blog/topics/developers-practitioner...

The contrast between the Uber and Google setups would be twofold. Google engineers weren't doing local builds anyway (unless they intentionally inflicted those upon themselves) because of Forge. The Forge builders already had 10000 CPU cores in 2010[1]. You can probably imagine how many cores Forge or its equivalent has today. Secondly Google doesn't suffer from the performance problems of a weird freeware VCS, because they don't use git or the git workflow model at all. They built their own VCS based on the workflow model from Perforce.

One funny aspect of Google moving development into cloud machines was that a decade before the process ran the other way. The desktop that was issued to most engineers was a production websearch machine turned sideways and stuck under your desk.

1: https://youtu.be/b52aXZ2yi08?t=1118

Re: Devpod: Remote development environment at Uber

#30

Post by why5s »

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…

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.
Post reply on HN