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

161–170 of 194 posts

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

#161

Post by dang »

dkarapetyan wrote: post #156
dang wrote: post #153

Earlier quoted context omitted.

Mine too, but that doesn't make it a good comment. In fact its first paragraph is almost a parody of the know-it-all internet comment. There are a zillion ways to make the same kind of argument thoughtfully. Talking about one's own concrete experiences helps. So does not acting like you know everything about somebody else's situation. Bloat is a problem, and so (in my view) is the kitchen-sink software culture of hau…

Point taken. I'll try to do better next time but it does get old after a while of seeing the same set of mistakes and articles parroted over and over again. Trivial problems blown out of proportions because people don't know the proper science, theory, and history and have opted to re-invent things badly. Uber is especially known for this since they re-invented/re-wrote basic geospatial algorithms in Go and hailed it…

I understand, but we need you to give us the experience and omit the dismissal. The former can dramatically improve the quality of this site; the latter only degrades it. And the former will actually be persuasive while the latter merely gets people's backs up (or makes them cheer if they happen to hate the same thing) without teaching the reader.

I get irritated at having to repeat the same things over and over, too, but the internet is basically stateless and so (sadly) is the software business. And like everyone, I get peevish when people say/do wrong things and act like they know what they don't. The longer one has been around, the more occasions one has to secrete bile. But it's a humor one must metabolize internally and not release into the community—hard work and not fun at first, but far more rewarding in its effects, and maybe our only chance at creating an actually functional culture.

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

#162

Post by habosa »

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 in locations without a client side update.

I'm biased for this next part (since I work on the product) but if you're interested in making your app have abilities like this check out Firebase Remote Config (https://firebase.google.com/docs/remote-config/). While setting up your own config service is not rocket science, having a free one with a web UI is pretty nice.

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

#163

Post by dkarapetyan »

dang wrote: post #161
dkarapetyan wrote: post #156

Earlier quoted context omitted.

Point taken. I'll try to do better next time but it does get old after a while of seeing the same set of mistakes and articles parroted over and over again. Trivial problems blown out of proportions because people don't know the proper science, theory, and history and have opted to re-invent things badly. Uber is especially known for this since they re-invented/re-wrote basic geospatial algorithms in Go and hailed it…

I understand, but we need you to give us the experience and omit the dismissal. The former can dramatically improve the quality of this site; the latter only degrades it. And the former will actually be persuasive while the latter merely gets people's backs up (or makes them cheer if they happen to hate the same thing) without teaching the reader. I get irritated at having to repeat the same things over and over, too…

Agreed.

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

#164

Post by Animats »

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

> Facebook originally tried to do that, then discovered that, as they grew, friends weren't local. Interesting. Do you have a link on that?

EE380 talk at Stanford with Facebook devs. They were there to talk about their PHP compiler, but got into how Facebook scales.

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

#166

Post by dang »

uberonhn wrote: post #158
gaius wrote: post #114

Earlier quoted context omitted.

Credit card processors and airlines did millions of transactions a day in the 1970s, and they managed it with CICS.

It sounds like you have no idea how credit card transactions were or are processed. They are almost exclusively file and batched once a day, even today. Back in the 1970s it was even worse because there was no real time authorization.

This is helpful information if accurate, but please edit incivility like "It sounds like you have no idea" out of your comments here. The site guidelines ask you to omit this sort of thing, so please post civil and substantive comments only:

https://news.ycombinator.com/newsguidelines.html

https://news.ycombinator.com/newswelcome.html

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

#167

Post by pfarnsworth »

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 love how any armchair quarterback on HN can sit back and dismiss the work of thousands of engineers as bloat, with no actual qualifications of their own.

Build a multi-billion dollar company that has satisfied customers around the world, and then let's hear what you have to say.

Let me guess, you also came up with the idea for Google Adsense and the iPhone in high school, right?

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

#168

Post by orf »

jdavis703 wrote: post #119
orf wrote: post #89

Earlier quoted context omitted.

> No armchair architect will ever take into account things like that An armchair architect would say it's not needed. They would question whether spending 50% of your response time generating a single sentence is in any way worth it, and wonder what kind of architectural mistakes led to that.

The problem with this line of reasoning is that it implies the business exists to serve the software. Unless you work at a tech-focused non-profit, the software actually exists to serve the business.

> the software actually exists to serve the business.

Sure it does, but the business also wouldn't exist without the tech in Ubers case (and a lot of other cases). And it's going to be your head on the line when you keep adding these 100ms sentences because the business wants it for no good reason and your page takes 3 seconds to load, and nobody buys anything from the site.

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

#169

Post by kod »

dkarapetyan wrote: post #159
kod wrote: post #157

Earlier quoted context omitted.

I'd love to hear why Kafka is not good software, and what open source alternatives are available that scale the way it does.

Same reason any other software is not good software. Chances are you don't need it and are reaching for a shiny tool. Kafka requires zookeeper and in my experience zookeeper is an operational nightmare. If you need an event bus then there are many out there that are much simpler and easier to maintain operationally with much simpler failure modes. Don't just reach for something because it has been the most common thi…

Many out there that scale like Kafka, so surely you can name some?

Yes, zookeeper is a turd, but it's a battle tested turd. Distributed systems aren't easy to get right.

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

#170

Post by robbles »

orf wrote: post #168
jdavis703 wrote: post #119

Earlier quoted context omitted.

The problem with this line of reasoning is that it implies the business exists to serve the software. Unless you work at a tech-focused non-profit, the software actually exists to serve the business.

> the software actually exists to serve the business. Sure it does, but the business also wouldn't exist without the tech in Ubers case (and a lot of other cases). And it's going to be your head on the line when you keep adding these 100ms sentences because the business wants it for no good reason and your page takes 3 seconds to load, and nobody buys anything from the site.

You're making the assumption that the additional features slowing down the service aren't adding value.

More common is a "death by 1000 cuts" scenario where the various causes of slowness are apparent to the developers, but quite difficult to remove because they've become necessary to the continued success of the business.

Post reply on HN