Lessons Learned From Scaling Uber To 2000 Engineers, 1000 Services, And 8000 Git Repositories

Video Notes

Two biggest ideas:

• Microservices are a way of replacing human communication with API coordination.
• Pure carrots, no sticks.

Microservices

• The time when things are most likely to break is when you change them. Uber is most reliable on the weekends when engineers aren’t making changes even though that’s when Uber is the busiest.
• Everytime you go to change something you risk breaking it. Does it make sense at some point to never touch a microservice? Maybe.
• The Good:
  • Microservices allow teams to be formed quickly and run independently. People are being added all the time.
  • Own your own uptime. You run the code that you write. All the service teams are on call for the services they run in production.
  • Use the best tool for the job. But best in what way? Best to write? Best to run? Best because I know it? Best because there are libraries? When you dig into it, best doesn’t mean a lot.
• The Obvious Costs:
  • Everything is an RPC.
  • Microservices deployment.
  • What if breaks?
• The Less Obvious Costs:
  • Everything is a tradeoff
  • You might choose to build a new service instead of fix something that’s broken. At some point the cost of always building around problems and cleaning up old problems starts to be a factor.
  • You find yourself trading complexity for politics. Instead of having awkward conversations, laden with human emotions, you can just write more software and avoid talking.
  • You get to keep your biases.

The Cost Of Having Lots Of Languages

What I Wish I Knew: having multiple languages can fragment culture. By embracing the microservices everywhere you can end up with camps. There’s a node camp, a Go camp, etc. It’s natural, people organize around tribes, but there’s a cost to embracing the strategy of having lots of languages everywhere.

Politics

• Politics happen whenever you make a decision that violates this property: Company > Team > Self.
  • You put the values of your self above the team.
  • The values of the team are put above the company.

Lessons learned

• Everything is a tradeoff.
• Trade complexity for politics.

Problems

• Lots of languages
• The cost of RPCs
• Operational issues
• Performance issues
• Logging
• Fanout tracing
• Load testing
• Failure testing
• Migration
• Open Source

Research on frequently seen technology.

Microservices

Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of loosely coupled services. Benefits:

* services are fine-grained and the protocols are lightweight. 
* improves modularity and makes the application easier to understand, develop and test. 
* parallelizes development by enabling small autonomous teams to develop, deploy and scale their respective services independently.
* enables continuous delivery and deployment. It allows the architecture of an individual service to emerge through continuous refactoring.

RESTful

What is REST?

• REST stands for Representational State Transfer. It is a set of design principles for making network communication more scalable and flexible.
• REST is a generic set of principles not specific to the Web. It can be applied to other kinds of networks such as embedded systems. REST is also not a protocol since it does not prescribe implementation details.

The Fielding Constraints

Fielding’s dissertation outlines a number of architectural constraints that a system must satisfy to be considered RESTful.

1. Client-server

   • the network must be made up of clients and servers.
   • A non-RESTful alternative to client-server architecture is event-based integration architecture. In this model, each component continuously broadcasts events while listening for pertinent events from other components. There’s no one-to-one communication, only broadcasting and eavesdropping

2. Stateless

   • Stateless does not mean that servers and clients do not have state, it simply means that they do not need to keep track of each other’s state.
   • When a client is not interacting with the server, the server has no idea of its existence.
   • The server also does not keep a record of past requests. Each request is treated as a standalone.

3. Uniform interface

   • The “uniform interface” constraint ensures that there is a common language between servers and clients that allows each part to be swapped out or modified without breaking the entire system.
   • This is achieved through 4 sub-constraints:
     1. Interface constraint 1: identification of resources
     2. Interface constraint 2: manipulation of resources through representations
     3. Interface constraint 3: self-descriptive messages
     4. Interface constraint 4: hypermedia

4. Caching

   • Server responses should be labelled as either cacheable or non-cacheable.
5. Layered system
   • There can be more components than just servers and clients. This means there can be more than one layer in the system.
   • However, each component is constrained to only see and interact with the very next layer.
6. Code on demand
   • This is the only optional constraint and refers to the ability for a server to send executable code to the client.

In summary, a RESTful system is any network that fulfills the Fielding Constraints. A RESTful system is meant to be flexible for different use cases, scalable to accommodate a large number of users and components, and adaptable over time.

SLA

A service-level agreement (SLA) is defined as an official commitment that prevails between a service provider and the customer.

• Fanout & tracing