101–110 of 194 posts
> Screenshots show Uber’s rider app in [...] China Interesting to see Google maps being used, isn't that blocked in mainland China?
Here's what it looked like for me last May: https://www.dropbox.com/s/9rkor22hn3q6z5t/IMG_2183.jpg?dl=0
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…
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
Earlier 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.
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.
> 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
Feature flags. Default off, but flip on a new path of code for a set of users.
You should deploy so often that it is routine. Deploy 50 times a day. You will find bugs at first, but eventually you should get to the point that you could deploy for every single commit and no one would notice. (Now they may not be a good idea depending on your risk tolerance and other things, but you should be ABLE to deploy every single commit).
Not saying these are simple things to do, but if you are approaching servers with a devops mindsets, you literally should not care about number of servers or datacenters.
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.
Earlier quoted context omitted.
>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…
If you have a clue, as you say, and still believe that it's a good idea to store critical data with NoSQL then I don't know what to say. Obviously you don't care enough that almost every NoSQL solution out there has been found to make false claims about their guarantees. The billions that have been sunk in the blackhole that's called NoSQL in the last decade is unprecedented. You don't have to change my mind. I have(…
> Many people choose the wrong tool for the job
I think that is far past database choice. I think many people build SPAs that end up hurting the product over a traditional setup. I think many people use microservices where a monolith would have much better performance and reliability.
As for the basic premise
> that people who use NoSQL for 99% of their projects are making the wrong choice.
Is perhaps kinda right? Some people may really only touch giant data sets. So for them always using NOSQL is smart. The people that write webapps with 12 users? More questionable.
Most cases you can decide if you need to leave RBMS with something like.
1) Do you need to store in the next year > 100GB of data that you need to access in realtime?
2) Do you need in the next year to store > 1TB of data that you need to access in semi-realtime?
3) Do you need in the next year to handle > 1000 writes per second?
4) Do you need in the next year to handle > 1000 reads per second?
Not a perfect guide, and I am sure you can think of edge cases that can still be dealt with in a RDBMS.. but it is a decent starting place. One tricky part is that if you are optimistic, almost any app can check off #3 or #4 (Like Uber but for Baby Strollers). Knowing how to realistically estimate demand for a possibly viral startup is hard.
Earlier quoted context omitted.
If you have a clue, as you say, and still believe that it's a good idea to store critical data with NoSQL then I don't know what to say. Obviously you don't care enough that almost every NoSQL solution out there has been found to make false claims about their guarantees. The billions that have been sunk in the blackhole that's called NoSQL in the last decade is unprecedented. You don't have to change my mind. I have(…
So I think a lot of people agree with you on > Many people choose the wrong tool for the job I think that is far past database choice. I think many people build SPAs that end up hurting the product over a traditional setup. I think many people use microservices where a monolith would have much better performance and reliability. As for the basic premise > that people who use NoSQL for 99% of their projects are making…
Another one that I'd add is: - "Are the records in each table in the hundred of millions? Then most probably you'll do fine with an RDBMS".
If you go above that, or you have operations that will extrapolate that number in the billions then you can offload them into whatever non-RDBMS storage you want and do your thing. But that's the thing with RDBMS, you can always move(or offload part of) your data to a non-RDBMS solution afterwards.
But doing the inverse? I wouldn't want to be in that person's shoes ;)
I have. It must have been my state school that turned them off. I know I could keep up there, but maybe they also turned me down because I'm 5 states away and they thought I wasn't worth the recruiters time.
edit: downvoter, if you could provide your rationale that would be great.
Earlier quoted context omitted.
So I think a lot of people agree with you on > Many people choose the wrong tool for the job I think that is far past database choice. I think many people build SPAs that end up hurting the product over a traditional setup. I think many people use microservices where a monolith would have much better performance and reliability. As for the basic premise > that people who use NoSQL for 99% of their projects are making…
The above is good as a rule of thumb indeed. Another one that I'd add is: - "Are the records in each table in the hundred of millions? Then most probably you'll do fine with an RDBMS". If you go above that, or you have operations that will extrapolate that number in the billions then you can offload them into whatever non-RDBMS storage you want and do your thing. But that's the thing with RDBMS, you can always move(o…
Earlier quoted context omitted.
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 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. > 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 Feature flags. Default off, but flip on a new pa…
Yep, this is change control 101. I used to have a boss who would go in and edit sprocs on the production server and never get them into source control. I finally just encrypted everything on the server so the only way to push out new code was to commit to source control. A sledge hammer yes, but sometimes it is required.
Use Terraform or some other tool to codify your entire infrastructure.
>You should deploy so often that it is routine. Deploy 50 times a day. You will find bugs at first, but eventually you should get to the point that you could deploy for every single commit and no one would notice. (Now they may not be a good idea depending on your risk tolerance and other things, but you should be ABLE to deploy every single commit).
This is a great point. At first it is terrifying, but then you realize that a deployment is so easy that bugs are generally not a big deal. Bugs happen, so the goal should be to shorten the time between bug found and fix deployed.
Earlier quoted context omitted.
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 i…
