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

21–30 of 194 posts

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

#21

Post by e1g »

I'd love to know how many people are responsible for devops/operations/app at various stages of any company's journey. Wikipedia says Uber employs 6,500 people so if even 15% of that is on the tech side of the business that's still 1,000+ people allocated to tech. I think this metric would be a useful reality check for a "modern" SaaS project with 3-10 people that's trying to emulate a backend structure similar to the big league.

There are 20+ complex tools listed in the stack, and to run a high-visibility production system would require high level of expertise with most of them. Docker, Cassandra, React, ELK, WebGL are not related in required skills/knowledge at all (as, for example, Go and C are). Is it 5 bright guys and girls managing everything, like the React time within Facebook? Or a team dedicated just to log analytics?

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

#22

Post by adamnemecek »

mikecke wrote: post #17
cynicalkane wrote: post #16

Earlier quoted context omitted.

What are you talking about? If you copy-paste the title you get all caps.

Oops, I didn't know the behavior persists.

I think that this is new though. I don't think it used to be like this (?). I'm on Chrome.

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

#23

Post by dkarapetyan »

e1g wrote: post #21

I'd love to know how many people are responsible for devops/operations/app at various stages of any company's journey. Wikipedia says Uber employs 6,500 people so if even 15% of that is on the tech side of the business that's still 1,000+ people allocated to tech. I think this metric would be a useful reality check for a "modern" SaaS project with 3-10 people that's trying to emulate a backend structure similar to th…

That's all bloat. Pure and simple. At the end of the day Uber just does routing and basic allocation. It's a simple operations problem that has been solved since the 70s and no one back then needed ELK, Docker, Cassandra, etc.

I've seen this bloat everywhere. It is usually a result of internal politics and posturing by management types. The kinds of people Steve Jobs would have called B and C players. Now the actual people operations is another matter entirely but the tech stack definitely doesn't need to be that complicated.

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

#24

Post by stickfigure »

praneshp wrote: post #8
stickfigure wrote: post #7

I've been sitting on the sidelines of the "Uber is great!" vs "Uber are a bunch of dicks!" war for quite some time now. I always figure every company of reasonable size contains elements of both. But geezus... this was posted with the title in all caps "THE UBER ENGINEERING TECH STACK, PART I: THE FOUNDATION". Presumably by someone at Uber. Is their corporate culture that arrogant?

Could you explain what is arrogant about it? The all caps doesn't come across as arrogant or weird to me on the blogpost.

When I saw the story, it stood distinctly apart on the HN homepage as the only story title with ALL CAPS LOOK AT ME. It was definitely a HN culture faux-pas. Alone by itself this is not a serious indictment, but coming from a company with a reputation for arrogance it seemed to be in particularly poor taste.

The title of the story on HN has since been corrected to normal case.

I'm not an Uber hater, if anything I'm inclined to defend the company. But posting ALL CAPS to HN is either arrogance or carelessness or (most likely) some combination of both. I would not normally pay attention except this is a company which already has a reputation, so maybe it's actually part of the corporate culture? Or maybe I'm overthinking it.

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

#25

Post by Animats »

It's interesting that they don't break the problem apart geographically. It's inherent in Uber that you're local. But their infrastructure isn't organized that way. Facebook originally tried to do that, then discovered that, as they grew, friends weren't local. Uber doesn't need to have one giant worldwide system.

Most of their load is presumably positional updates. Uber wants both customers and drivers to keep their app open, reporting position to Master Control. There have to be a lot more of those pings than transactions. Of course, they don't have to do much with the data, although they presumably log it and analyze it to death.

The complicated part of the system has to be matching of drivers and rides. Not much on that yet. Yet that's what has to work well to beat the competition, which is taxi dispatchers with paper maps, phones, and radios.

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

#26

Post by dang »

cynicalkane wrote: post #16
mikecke wrote: post #13

For those of you complaining about the title being all caps, it was done so for aesthetic purposes. Which means somehow the submitter went through the time to uppercase each character of the HN title before submitting. text-transform: uppercase;

What are you talking about? If you copy-paste the title you get all caps.

> What are you talking about?

Please don't be rude in comments here.

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

#27

Post by joering2 »

Sounds like a very solid foundation! I'm glad to see they have sufficient system in place to continue spamming the heck out of people who never opted into their advertisement in the first place.

/sarcasm

I only wish LE would treat CAN-SPAM seriously and put more sources into criminal enforcement.

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

#28

Post by asdfaoeu »

Animats wrote: post #25

It's interesting that they don't break the problem apart geographically. It's inherent in Uber that you're local. But their infrastructure isn't organized that way. Facebook originally tried to do that, then discovered that, as they grew, friends weren't local. Uber doesn't need to have one giant worldwide system. Most of their load is presumably positional updates. Uber wants both customers and drivers to keep their…

> We assign cities to the geographically closest data center, but every city is backed up on a different data center in another location.

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

#29

Post by Animats »

dkarapetyan wrote: post #23
e1g wrote: post #21

I'd love to know how many people are responsible for devops/operations/app at various stages of any company's journey. Wikipedia says Uber employs 6,500 people so if even 15% of that is on the tech side of the business that's still 1,000+ people allocated to tech. I think this metric would be a useful reality check for a "modern" SaaS project with 3-10 people that's trying to emulate a backend structure similar to th…

That's all bloat. Pure and simple. At the end of the day Uber just does routing and basic allocation. It's a simple operations problem that has been solved since the 70s and no one back then needed ELK, Docker, Cassandra, etc. I've seen this bloat everywhere. It is usually a result of internal politics and posturing by management types. The kinds of people Steve Jobs would have called B and C players. Now the actual…

I have to admit, I could see this running for a city the size of SF on a desktop machine under the table at the taxi depot. Uber has 11,000 drivers in SF, but probably only a few thousand are on at any one time. A ride takes a few minutes, so if you figure 3,000 active drivers and 4 rides per hour, that's only about 3 ride transactions per second. You have a transaction at ordering, one at ride start, and one at ride end. Plus you have tracking of where all the active drivers are, pinging maybe once a minute. That adds up to only at 10-20TPS. You can offload the routine web and app stuff to some front end machines. And you want to do some analysis every minute or two to see where there are "surges".

The only non-trivial part of this is assigning drivers to rides.

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

#30

Post by asdfaoeu »

dkarapetyan wrote: post #23
e1g wrote: post #21

I'd love to know how many people are responsible for devops/operations/app at various stages of any company's journey. Wikipedia says Uber employs 6,500 people so if even 15% of that is on the tech side of the business that's still 1,000+ people allocated to tech. I think this metric would be a useful reality check for a "modern" SaaS project with 3-10 people that's trying to emulate a backend structure similar to th…

That's all bloat. Pure and simple. At the end of the day Uber just does routing and basic allocation. It's a simple operations problem that has been solved since the 70s and no one back then needed ELK, Docker, Cassandra, etc. I've seen this bloat everywhere. It is usually a result of internal politics and posturing by management types. The kinds of people Steve Jobs would have called B and C players. Now the actual…

> At the end of the day Uber just does routing and basic allocation.

The thing is though that that algorithm is easily copied as evidenced by lyft and etc. So really Uber's business model needs to be all about differentiation, marketing, analytics and prediction otherwise they won't survive.

I think analytics and other fuzzy avenues are where those technologies shine.

Post reply on HN