What I Wish I Had Known Before Scaling Uber to 1000 Services • Matt Ranney • GOTO 2016
Why Hacker News recommends it
Often brought up as an honest account of microservice sprawl, including the fact that nobody at Uber knew exactly how many services existed.
What it is
Matt Ranney of Uber talks at GOTO Chicago 2016 about what Uber learned from growing past 1,000 production microservices. He covers regrets, sprawl and organizational effects.
Recommended by 3 HN commenters across 3 different months, 2016 to 2023.
What Hacker News said
Recommends smcl · 2016-10 · on “Why's that company so big? I could do that in a weekend”
Joking aside I enjoyed that video ( [this video] - for those who didn't see it), the presenter was pretty honest and way more open than I expected. I'm just so curious how those services break down - if it's genuinely on the "lstrip as a service" level or whatever, whether that's "1,000 services" figure was actually a relatively simple API with 10 versions at various levels of deprecation, whether he meant it was 1,000 different service endpoints (250 services each with POST, GET, PUT, DELETE) or what. I want to know more basically :)
Recommends kartD · 2017-09 · on “Ask HN: Recommended (recent) videos for a Lunch and Learn”
Little drunk so bear with me :) Rich Hickey: Clojure concurrency[ [LINK] ] Keynote - Rust: confident, productive systems programming by Aaron Turon [ [LINK] ] RustConf 2016 - A Modern Editor Built in Rust by Raph Levien [ [LINK] ] Microservices at Netflix Scale: Principles, Tradeoffs & Lessons Learned[ [LINK] ] What I Wish I Had Known Before Scaling Uber to 1000 Services[ [this video] ] Dynamic Code Optimization and the NVIDIA Denver Processor [ [LINK] ] * if you can get anything on Apple's Ax series that's even better
Recommends jppope · 2018-07 · on “Ask HN: What are the things keep in mind while giving/preparing for a tech talk?”
1) Do not attempt to live code. change your code via version control, build small videos, copy and paste... whatever you do... do not try and live code 2) Read "The presentation secrets of Steve Jobs" ... its not really about Steve Jobs so much as its about how to be a great presenter. 3) building or writing a talk is significantly less important than the delivery... which means that more of your time should be spent on how to deliver the speech (recording I find is the best way to practice) 4) Pick a single thing and do it well, do not attempt to put too much into a talk or tackle something massively complex. 5) Make sure that everyone is walking away with something they can actually use. T
Cites securingsincity · 2017-02 · on “Uber launches 'urgent investigation' into sexual harassment claims”
Total armchair observer viewpoint - In reading Susan's blog, there are a lot of sexual harassment claims but there are many claims of cloak and dagger behavior. This points to a dysfunctional organization that lacks trust. And in that, I couldn't help but think of Conway's law [1] and the video from the goto; conference [2] about Uber's infrastructure. "We have so many services in production we don't even know how many there are." This may reflect a few different trust issues. One of which includes "Not invented here" thus building services that are duplicative. The goal of which is to show value and get promoted. Given the blog, the communication and reporting structure is also broken. Whic
Cites itsmenotyou · 2017-12 · on “On the Moral Economy of Tech (2016)”
I think as technologists we have a natural preference for clean technological solutions that don't involve politics or messy interpersonal relationship issues. Failing to confront that whole human sphere of life leads to negative consequences everywhere, and the talk does a great job of pointing out some of the macro social effects. On a similar note but a more localized scale I'm reminded of this talk on one of the downsides of moving to microservices being that people can avoid difficult conversations [this video]
Cites tzhenghao · 2018-07 · on “Why Google Stores Billions of Lines of Code in a Single Repository (2016)”
Having worked at different companies adopting both monorepo and the multiple repos approach, I find monorepo a better normalizer at scale in consolidating all "software" that runs the company. Just like what many commenters here have mentioned, the monorepo approach is a forcing function on keeping compatibility issues at bay. What you don't want is to end up in a situation where teams reinvent their own wheels instead of building on top of existing code, and at scale, I think the multiple repo approach tends to breed such codebase smell. [1] I'm sure 8000 repos is living hell for most organizations. [1] - [this video]
Cites djsumdog · 2020-06 · on “Microservices Considered Harmful (2019)”
At a goto; talk, an Uber engineer said they had so many microservices it was impossible to really count how many they had: [this video]
Critical developer2 · 2016-10 · on “Why's that company so big? I could do that in a weekend”
You're going to talk about Uber? Watch this video: [1]. He talks about every regret regarding their infrastructure. At first you kind of nod your head along with "yeah, it's not that easy", but as he keeps talking you can't help but wonder why the company has absolutely no internal technical direction whatsoever . They employ over 2000 engineers (just devs, excluding support staff, etc.). They use micro-services designed to the point where teams can't reuse pre-existing services. They are rewriting the same functionality over and over, and over and over again, as separate teams don't even have a clue what has already been written. Pick a piece of functionality you need. There are straight up