-
2011: running activity/service "barely running in production"
- reliability issues
- little tests
- features deployed in months
-
2012: their own backend
- "deep vertical" stack
- 9 teams on the same codebase supporting 14 products
- 2 days developing, 15 "stabilizing"
- still taking months to take features out
-
2013: get to green
- Pairing/tdd
- 100% peer reviews on pull requests
- 5-10 days developing every 15
- strict deployment process and change control
- reduced to 3 development teams
- features deployed in weeks to months
- product perspective: "slow and stable", not ideal
-
2014:
- 15 projects, each with 700-2klocs
- open source feel - pick up a project and improve it
- 0 downtime, high scale
- features deployed in hours
-
"Normalization is the root of all evil"
-
Key points with microservices:
- Immutable deployment units
- Share nothing (Cassandra)
- Continuous delivery
-
Architecture
- Asgard
- Eureka / Ribbon for dynamic discovery
- Zuul
- SNS/SQS
-
Breaking nested resources in the representation
- Eg: "activity" had a user, device, goal, etc
- Now that is represented by 4 different apis
-
Lessons
- Netlifx OSS helped
- Strong API contracts
- Share nothing
Last active
August 29, 2015 14:09
-
-
Save pedro/fbb1bd7bd6db78e4dfa7 to your computer and use it in GitHub Desktop.
Nike's journey to microservices
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment