February 12, 2020

What I wish I had known before scaling Uber to 1000 services

Speaker

Matt Ranney, Senior Staff Engineer at Uber

Thoughts

Many of the situations described by Matt I experienced at Captalys while building the current infraestructure of the company. There are a lot of fallacies about microservices online and the hype effect of an unkown technology is completely dangerous.

Microservice is simple, microserviceS is a whole lot of new problems.

Think carefully.

Quotes

Uber made a 10x growth in one year.

Might trade complexity for politics. "Write more software and avoid arguing with other people"

history:

  1. pre-history PHP (outsourced)

  2. Dispatch Node.JS, moving GO

  3. Core Services Python, moving to GO

  4. Maps Python and Java

  5. Data Python and Java

  6. Metrics GO

How many repos? Many is good, one is good, many is bad, one is bad…​

Recommendations

  1. Everytime you change something, has a lot of risk of breaking stuff

  2. All your services teams are on-call by their services running in production

  3. Distributed Systems is REALLY harder to work with than a single peace of software

  4. Hard to share code, hard to move between teams, fragments the culture

  5. RPC: HTTP/REST gets complicated

  6. JSON needs a schema, RPCs are slower than PCs

  7. Operational problems: understand a service in the larger context

  8. Some kind of tracing is required! And most of the time, tracing takes a lot of effort

  9. Need consistent, structured logging

  10. Load testing: need to test against production

  11. Load testing: without breaking metrics, preferably all the time

  12. Load testing: all systems needs to handle "test" traffic

  13. Failure testing ---- WIWIK: people won’t like it

  14. Migrations: old stuff still has to work

Tags: architecture