Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Uber Engineering Tech Stack, Part I: The Foundation

eng.uber.com

Post reply on HN
Print view View original

181–190 of 194 posts

Re: The Uber Engineering Tech Stack, Part I: The Foundation

#181

Post by rantanplan »

dominotw wrote: post #146
rantanplan wrote: post #144

Earlier quoted context omitted.

FB and all big companies are a very bad example. They have ton of resources and usually they don't use vanilla products, since they have the engineering capacity to support their own forked versions. e.g. see their own version of PHP. Also distributing reads is easy, writes... not so much. NoSQL systems usually offer distributed writes with the caveat of eventual consistency. RDBMS have referential integrity and othe…

>RDBMS have referential integrity and other constraints which by definition cannot migrate into a distributed environment. so, Use RDBMS if your data can be handled by a single machine( or have the resources of FB) ? '99% ppl need RDBMS' argument boils down to 99% of ppl have data that can be handled by a single machine RDBMS. Is that a good conclusion?

The single machine shouldn't be the deciding factor.

If your application is like most apps(far more reads than writes) then you can easily distribute the load across multiple machines. If you have more writes than reads(quite rare but still) then scaling an RDBMS will be challenging.

In this case, if eventual consistency is something you can live with, a NoSQL store might be best for you.

Re: The Uber Engineering Tech Stack, Part I: The Foundation

#182

Post by ajslater »

methehack wrote: post #155
scaleout1 wrote: post #143

Earlier quoted context omitted.

Thats an interesting approach. One question though, in our use case user often travel from city to city and country to country. How do you model that if you are only using local DC and local replications?

I think the regional keyspaces would be have to be caches -- denormalize it, basically. Pop/re-fresh people into the geo-based caches as they moved around. Truth sits behind it, centralized (perhaps partitioned in some way that makes sense globally but is sub-optimal from a regional cache perspective). Might not be worth it -- hard to know from here. :)

afaik, this is how Facebook does it, but with regional sources of truth. If you signed up for FB in Paris and move to San Francisco, your master profile lives in Europe in perpetuity and you'll use your regional cache forever in the USA. The number of people moving far away from their home DC's should be a reasonably small fraction of the total for it not to matter.

Re: The Uber Engineering Tech Stack, Part I: The Foundation

#183

Post by dang »

pfarnsworth wrote: post #165

You mean any other software except for your own software right? Because it certainly sounds like you're the purveyor of what great software is, and your talent shines through your comments so clearly.

Even if you're correct in this reading, please don't get personally rude about it.

We detached this comment from https://news.ycombinator.com/item?id=12154325 and marked it off-topic.

Re: The Uber Engineering Tech Stack, Part I: The Foundation

#184

Post by nojvek »

ryanlm wrote: post #107

I just got rejected from them. I applied for a SE position, but they didn't like me I guess. They send you this really condescending rejection letter. I showed them my programming language that I built in C from scratch, and also my data structure library where I implement all the common data structures found in high level languages that I built from scratch in C, among the many projects I have. It must have been my…

I've interviewed at Uber as well. The truth is failing / passing an interview is a really bad indicator on how good a coder you are. My uber interview was like any other interview. Don't take it personally. Keep calm and move on.

Re: The Uber Engineering Tech Stack, Part I: The Foundation

#185

Post by krinchan »

brianwawok wrote: post #154
krinchan wrote: post #125

Earlier quoted context omitted.

This is so weird. I hear this all the time. At my place of employment, we all have the ssh keys into our EC2 instances, but no one configures them. Ever. Period. Those ssh keys are purely for either validating changes in a test environment (like to .ebextensions) or diagnosing production issues (why did Puma fall over this time? why isn't syslog output making it to loggly?). Of course, we lean heavily on Elastic Bean…

I'm very very pro devops. But I am cautious about auto scale. It adds a lot of complexity. If your app has predprtable load it may simplify stuff a lot to not auto scale. Think a b2b app with manual account creation. You know your user levels. 0 reason to turn on auto scale.

...so you run the servers you need for peak load 24/7? Ew. So much money just thrown away because "it's too complicated". We just scale based off of Network Out and only really spent a week finding the right threshold.

Re: The Uber Engineering Tech Stack, Part I: The Foundation

#186

Post by sandGorgon »

habosa wrote: post #162
sandGorgon wrote: post #35

What I'm really wondering about is their app. The UI of the app can be impacted without an app update. For example the UI during the pride parade. Or minute of silence ( http://gizmodo.com/uber-makes-riders-take-a-moment-of-silenc... ) I wonder what's the architecture of the app and the API for this.

Most major apps phone home for a big config object (likely JSON) at the start of a run. This would contain things like car icons, etc. You can see an example of this in the 3p Uber API which has a call to get which car types are available at a given geolocation. This API returns not only the vehicle types (Uber X, Uber Black, etc) but also a jpeg icon representing the car. In this way Uber can roll out new car types…

That is for your answer. I suppose that the interesting code is on the app side rather than the server side (which basically returns a Bunch of Json) How do you architect a view layer that's so malleable - for example even the routes in Uber were shown in rainbow during pride.

Re: The Uber Engineering Tech Stack, Part I: The Foundation

#187

Post by seanp2k2 »

brianwawok wrote: post #152
danpalmer wrote: post #137

Earlier quoted context omitted.

> Don't do that. No one is allowed to ssh to boxes. If you need to enforce it by blowing up and rebuilding all servers once per week, do that. I'd love to do that. I'd love to have no access to production servers, but ultimately that requires far more work to get right than Ansible configuring the same machines again and again. It also means you can't use dedicated hardware as easily, which restricts performance. It'…

You can devops dedicated hardware. It's a little bit different but not that much. Heck there are boot2docker and such that let you just run docker on bare metal.

>docker >bare-metal

To some, no virtualization is still best.

Edit: you can still PXE boot immutable images.

Re: The Uber Engineering Tech Stack, Part I: The Foundation

#188

Post by brianwawok »

seanp2k2 wrote: post #187
brianwawok wrote: post #152

Earlier quoted context omitted.

You can devops dedicated hardware. It's a little bit different but not that much. Heck there are boot2docker and such that let you just run docker on bare metal.

>docker >bare-metal To some, no virtualization is still best. Edit: you can still PXE boot immutable images.

I'm not sure boot2docker even has a virtualization level. Havent dug super far into it.

Re: The Uber Engineering Tech Stack, Part I: The Foundation

#189

Post by brianwawok »

krinchan wrote: post #185
brianwawok wrote: post #154

Earlier quoted context omitted.

I'm very very pro devops. But I am cautious about auto scale. It adds a lot of complexity. If your app has predprtable load it may simplify stuff a lot to not auto scale. Think a b2b app with manual account creation. You know your user levels. 0 reason to turn on auto scale.

...so you run the servers you need for peak load 24/7? Ew. So much money just thrown away because "it's too complicated". We just scale based off of Network Out and only really spent a week finding the right threshold.

How long does your stack take to add a server. 3 minutes?

I have created a lot of services that couldn't have crappy perf for 3 minutes every time the load scales. Especially since in many apps the most expensive part is storage and dbs which cannot auto scale.

So say you spend 1k a month in your dbs and $100 for peak web load. You could spend a week fixing auto scaling bugs and try to save $25 by scaling web nodes down... But then you still have bad perf every time load spikes. I would not do that to save $25. I would question a company I work for that did that.

You need to be scaling up and down for hundreds of dollars per swing and have big spike loads before you add the complexity of auto scale.

Post reply on HN