> Screenshots show Uber’s rider app in [...] China
Interesting to see Google maps being used, isn't that blocked in mainland China?
The Uber Engineering Tech Stack, Part I: The Foundation
71–80 of 194 posts
Re: The Uber Engineering Tech Stack, Part I: The Foundation
#72I'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…
Like bureaucracy, the complexity of your tech stack grows to accommodate the number of people available to work on it. Go crazy on the hiring, and what do you expect all those people to do all day?
Re: The Uber Engineering Tech Stack, Part I: The Foundation
#73Earlier quoted context omitted.
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.
That's their business model? Really?
I think we both know that their business is nothing to do with the technology they use.
Re: The Uber Engineering Tech Stack, Part I: The Foundation
#74It'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…
I work on an uber-like system, but with ~3 backend devs rather than 100s. We made the opposite decision, cloning our full stack for each new market. That's great for scalability, but is a nightmare for devops. If anything we want to find a way to move to one global system, And then slice down the bits that can be local: Eg. Create a local order matching service, but keep orders, payments, and user accounts global
As far as I'm aware, Hailo (>3 backend devs, not quite 100s) did exactly this as well, and the ex-Hailo devs I've spoken to considered it a pretty bad move. It took them ages to refactor into a global system if I remember rightly.
Re: The Uber Engineering Tech Stack, Part I: The Foundation
#75Earlier quoted context omitted.
> It is however interesting that we used relational databases for virtually everything for decades even though SQL is suboptimal at most things You have no clue what SQL or ACIDity is. For 99% of the cases SQL/RDBMS is the right choice. You probably think you belong in that 1%, but from your comment, I suspect you do not. > I choose to use NoSQL for virtually all my projects That's because you have no important data…
Why do you think NoSQL means not important data? MongoDB eats data but I am not sure every NoSQL database does. NoSQL does add certain kinds of complexity, but also simplifies certain problems. Depends where your hard problems are..
MongoDB doesn't eat data any more than any other database.
It's used by eBay, Foursquare, Adobe, Facebook etc.
And NoSQL databases underpin most of the popular websites around today. It's nonsense to assume all of that data isn't valuable.
Re: The Uber Engineering Tech Stack, Part I: The Foundation
#76Earlier quoted context omitted.
>because of the one thing it does well. This "one thing it does well" business is then presented as : "using the right tool for the right job" and it's difficult to argue against that because the counterpart can easily deride you as a fanatic of some technology, someone not objective enough, etc... It is however interesting that we used relational databases for virtually everything for decades even though SQL is subo…
> It is however interesting that we used relational databases for virtually everything for decades even though SQL is suboptimal at most things You have no clue what SQL or ACIDity is. For 99% of the cases SQL/RDBMS is the right choice. You probably think you belong in that 1%, but from your comment, I suspect you do not. > I choose to use NoSQL for virtually all my projects That's because you have no important data…
>You have no clue what SQL or ACIDity is.
That's quite an attack. I trained for an Expert SQL certification from Microsoft back then, when I was writing 3000K+ long stored procedures to migrate an Access application at a fortune 40 company. So I know what it is and I know quite a good deal about RDBMS. I'm not among those who criticize what they don't know.
Regarding the gist of your comment on NoSQL, I haven't been able to convince people coming from where you are with two days of meetings in a row, so I'm fairly confident I'm not going to change your mind on HN.
Re: The Uber Engineering Tech Stack, Part I: The Foundation
#77Earlier quoted context omitted.
I work on an uber-like system, but with ~3 backend devs rather than 100s. We made the opposite decision, cloning our full stack for each new market. That's great for scalability, but is a nightmare for devops. If anything we want to find a way to move to one global system, And then slice down the bits that can be local: Eg. Create a local order matching service, but keep orders, payments, and user accounts global
If you are doing devops, wouldn't deploying to 1 data center vs 20 be no more work? It's just a loop around a script.
All it takes is for one server in one datacenter to be slightly different, or perhaps you had a bugfix that needed to go out for users in one area, but you couldn't take the risk of a flaky deploy for the areas that didn't need it, now you've got a deploy that will be a lot more complicated or error-prone than a loop around deployment to one location.
Re: The Uber Engineering Tech Stack, Part I: The Foundation
#78Earlier quoted context omitted.
If you are doing devops, wouldn't deploying to 1 data center vs 20 be no more work? It's just a loop around a script.
All it takes is for one server in one datacenter to be slightly different, or perhaps you had a bugfix that needed to go out for users in one area, but you couldn't take the risk of a flaky deploy for the areas that didn't need it, now you've got a deploy that will be a lot more complicated or error-prone than a loop around deployment to one location.
All it takes is for one server in one datacenter to be slightly different
But doesn't a global system still run on multiple DCs, at least for redundancy?
perhaps you had a bugfix that needed to go out for users in one area, but you couldn't take the risk of a flaky deploy for the areas that didn't need it
But if you have a single global system, you can't even make that decision.
To be clear, I'm not arguing against it, I'm just trying to understand why, since my first instinct would be to divide geographically as well.
Re: The Uber Engineering Tech Stack, Part I: The Foundation
#79Earlier quoted context omitted.
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…
Indeed. Most SaaS operations are over-provisioned both in terms of hardware and software.
And over-provisioned in terms of employees, I'd add.
Re: The Uber Engineering Tech Stack, Part I: The Foundation
#80Earlier quoted context omitted.
Why do you think NoSQL means not important data? MongoDB eats data but I am not sure every NoSQL database does. NoSQL does add certain kinds of complexity, but also simplifies certain problems. Depends where your hard problems are..
Because in the 2 decades I'm in the industry I see RDBMS make the world spin and NoSQL DBs destroying companies and families. MongoDB and CouchDB eat data for breakfast, I know that from 1st hand experience. And all the others DBs that claim that do not keep cropping up in Aphyr's blog. I ain't saying that all NoSQL dbs are useless. I'm just saying that proposing and choosing an RDBMS solution is going to be the righ…
In the last 2 decades in the industry as well I've never lost data with MongoDB, Riak or Cassandra but have with Oracle, DB2 and PostgreSQL. After all databases are just software and there will always be bugs. Some people just get tripped up by different ones.
And you are woefully ignorant to think the RDBMS is the right choice for 99% of projects. Especially since you think that the 1% of remaining users are purely worried about scalability. Hint: think about the schema problems associated with storing auto generated features from deep learning models.