What I Wish I Had Known Before Scaling Uber to 1000 Services • Matt Ranney • GOTO 2016

Joking aside I enjoyed that video ( [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 :)

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[ [VIDEO] ] Dynamic Code Optimization and the NVIDIA Denver Processor [ [LINK] ] * if you can get anything on Apple's Ax series that's even better

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. This doesn't require it be a hard skill... "Soft" or philosophical utilities are just as good 6) Have Fun and be funny... Speakers have a tendency to want to show off the size of their intellect, and the level their competency- having a speech be entertaining is way way more important. 7) DO NOT READ FROM YOUR SLIDES. know your shit. slides are supplementary Extra Credit. Here's a collection of some fantastic technical speeches: * [LINK] * [LINK] * [LINK] * [LINK] * [LINK] * [VIDEO]

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. Which, results in >1000 services in production and it being unclear how many there are and what they all do. Most likely, this is how the teams are structured as well. [1] - [LINK] [2] - [VIDEO]

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 [VIDEO]

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] - [VIDEO]

At a goto; talk, an Uber engineer said they had so many microservices it was impossible to really count how many they had: [VIDEO]

Apparently they started at 1000 and went from there... "What I Wish I Had Known Before Scaling Uber to 1000 Services" - [VIDEO]