Video and slides synchronized, mp3 and slide download available at URL http://bit.ly/1CD6by9. Steven Ihde and Karan Parikh discuss about tools and frameworks built in order to help LinkedIn's transition to microservices, including their URN resolution engine and the Rest.li API Hub. Filmed at qconsf.com. Steven Ihde is Director of Service and Presentation Infrastructure at LinkedIn. Karan Parikh is a software engineer on the Service Infrastructure team at LinkedIn.

1. From a monolith to
microservices + REST
The evolution of LinkedIn’s service architecture
by Steven Ihde and Karan Parikh (LinkedIn)

2. InfoQ.com: News & Community Site
• 750,000 unique visitors/month
• Published in 4 languages (English, Chinese, Japanese and Brazilian
Portuguese)
• Post content from our QCon conferences
• News 15-20 / week
• Articles 3-4 / week
• Presentations (videos) 12-15 / week
• Interviews 2-3 / week
• Books 1 / month
Watch the video with slide
synchronization on InfoQ.com!
http://www.infoq.com/presentations
/linkedin-microservices-urn

3. Purpose of QCon
- to empower software development by facilitating the spread of
knowledge and innovation
Strategy
- practitioner-driven conference designed for YOU: influencers of
change and innovation in your teams
- speakers and topics driving the evolution and innovation
- connecting and catalyzing the influencers and innovators
Highlights
- attended by more than 12,000 delegates since 2007
- held in 9 cities worldwide
Presented at QCon San Francisco
www.qconsf.com

6. Leo
● Our original codebase
● Java, Servlets, JSP, JDBC
Leo
Oracle
4

7. Remote Graph
● Graph: member-to-member connection
graph
● Complex graph traversal problems not
suited to SQL queries
● RPC was used to keep it separate from Leo
● Our first service
5

8. Remote Graph
Leo
Oracle
Graph
RPC
JDBC
Databus
6

9. Mid/Back Tier Services
● “Back” tier services encapsulate data
domains
● “Mid” tier services provide business logic
● We applied the service pattern to many
domains, e.g. member profiles, job postings,
group postings
7

10. Front Tier Services
● “Front” tier services aggregate data from
many domains
● Transform the data through templates to
present to the client
● Should be stateless for scaling purposes
8

11. Service Explosion
● Over 100 services by 2010
● Most new development occurring in
services, not Leo
● Site release every two weeks
9

12. Architectural Challenges
● Test failures
● Incompatibilities
● Complex orchestration
● Rollback difficult or impossible
● Complex dependencies between services
10

13. Microservices?
● Services were fine grained
● But monolithic build and release process
did not allow us to realize the benefits of
microservice architecture
11

14. Solutions
● Continuous delivery
● Break apart the code base
● Devolution of control
● Strict backwards compatibility
● Better defined boundaries between tiers
12

15. Continuous Delivery
● Shared trunk
● Pre- and post-commit automated testing
● Easy promotion of builds to production
environment
13

16. Decentralize Codebase
● Separate, independently buildable
repositories
● Shared trunk within each repository
● Versioned binary dependencies between
repositories
14

17. Devolution of Control
● Service owners control release schedule,
release criteria
● Service owners are responsible for
backwards compatibility
● Services must release independently
15

18. Backwards compatibility
● Insulates teams from each other at runtime
● Allows service owners to deploy on their
own schedule without impacting clients
16

19. Boundaries Between Tiers
● Limit aggregation to the front tier
● Limit crosstalk in the back tier:
“superblocks”
17

20. Boundaries Between Tiers
18

21. Java RPC
● Difficult to maintain backwards compatibility
● Verb-centric APIs
● Use case specific APIs
● Difficult to navigate the proliferation of
APIs
19

22. Rest.li plus Deco
equals Microservices
at LinkedIn

23. What is Rest.li?
“Rest.li is an open source REST framework
for building robust, scalable RESTful
architectures using type-safe bindings and
asynchronous, non-blocking I/O.”
Primarily JSON over HTTP.
21

24. Why Rest.li?
● Polyglot (frontend) ecosystem - Java,
Scala, Python, Node.js, Objective-C
● Uniform service interfaces (REST)
22

25. The Rest.li stack
Rest.li Data layer and RESTful operations
D2 Dynamic discovery and load balancing
R2 Network Communication
23

26. Request Response (R2)
● REST abstraction that can send messages
over any application layer protocol (HTTP,
PRPC (old custom LinkedIn protocol))
● Client - fully asynchronous Netty
● Server - Jetty, Netty (experimental)
Rest.li
D2
R2
24

27. Dynamic Discovery (D2)
● Apache ZooKeeper
● Dynamic server discovery
● Client side software load balancing
● D2 service
Rest.li
R2
D2
25

28. Rest.li
● Data using PDSCs (Pegasus Data
Schemas)
● RESTful API that developers use to build
services
● CRUD + finders + actions
● API and data backwards
compatibility checking
R2
D2
Rest.li
26

29. 830 Rest.li resources.
90 billion Rest.li calls/day across
multiple datacenters.
65% service-to-service calls.

30. What is deco?
28

31. Aside: Normalized Domain Models
● Links over inclusion (denormalization)
● URNs are fully qualified
foreign keys
InfluencerPost
Long id
String title
String content
URN author
Member
Long id
String firstName
String lastName
String summary
URN company
29

32. What is Deco?
● URN resolution library
● What data you want, not how you want it
Time
1
2
3
30

33. Deco Example: Influencer Post
Dummy Post
by Karan Parikh
at LinkedIn
Hi QCon!
/influencerPosts
/influencerPosts
/companies
/profiles
31

34. Deco Example: Influencer Post
deco://influencerPosts/123?projection=(title,
content, author~(firstName, lastName,
company~(companyName)))
32

35. Three services.
One client call.
Deco.

36. Rest.li plus Deco
equals Microservices
at LinkedIn

37. How Rest.li enables Microservices
● Rest.li + D2 facilitate domain specific
services
● Services can easily configure clients via D2
● D2 helps us scale the architecture
35

38. How Deco enables Microservices
● Deals with service explosion
● Abstracts away services from clients
36

39. Challenges
● Coordinating a massive engineering effort.
(LiX to the rescue!)
● Ensuring uniform RESTful interfaces
● Performance
Rest.li API Hub37

40. Wins
● All languages talk to the same service
● Developer productivity
● Reduction of hardware load balancers
● Ability to expose APIs directly to third
parties
38

43. LinkedIn Microservices

44. Questions?

45. References and links
● Rest.li: http://rest.li/
● Rest.li API Hub: https://github.com/linkedin/rest.li-api-hub
● Rest.li user guide: https://github.com/linkedin/rest.li/wiki/Rest.li-User-Guide
● Modeling resources with Rest.li:
https://github.com/linkedin/rest.li/wiki/Modeling-Resources-with-Rest.li
● LinkedIn engineering blog posts about Rest.li:
http://engineering.linkedin.com/architecture/restli-restful-service-
architecture-scale http://engineering.linkedin.com/restli/linkedins-restli-
moment
● LinkedIn’s GitHub projects http://linkedin.github.io/
43

46. Watch the video with slide synchronization on
InfoQ.com!
http://www.infoq.com/presentations/linkedin-
microservices-urn