Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

From a Monolith to Microservices + REST: the Evolution of LinkedIn's Service Architecture

9,129 views

Published on

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.

Published in: Technology

From a Monolith to Microservices + REST: the Evolution of LinkedIn's Service Architecture

  1. 1. From a monolith to microservices + REST The evolution of LinkedIn’s service architecture by Steven Ihde and Karan Parikh (LinkedIn)
  2. 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. 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
  4. 4. Leo ● Our original codebase ● Java, Servlets, JSP, JDBC Leo Oracle 4
  5. 5. 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
  6. 6. Remote Graph Leo Oracle Graph RPC JDBC Databus 6
  7. 7. 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
  8. 8. 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
  9. 9. Service Explosion ● Over 100 services by 2010 ● Most new development occurring in services, not Leo ● Site release every two weeks 9
  10. 10. Architectural Challenges ● Test failures ● Incompatibilities ● Complex orchestration ● Rollback difficult or impossible ● Complex dependencies between services 10
  11. 11. Microservices? ● Services were fine grained ● But monolithic build and release process did not allow us to realize the benefits of microservice architecture 11
  12. 12. Solutions ● Continuous delivery ● Break apart the code base ● Devolution of control ● Strict backwards compatibility ● Better defined boundaries between tiers 12
  13. 13. Continuous Delivery ● Shared trunk ● Pre- and post-commit automated testing ● Easy promotion of builds to production environment 13
  14. 14. Decentralize Codebase ● Separate, independently buildable repositories ● Shared trunk within each repository ● Versioned binary dependencies between repositories 14
  15. 15. Devolution of Control ● Service owners control release schedule, release criteria ● Service owners are responsible for backwards compatibility ● Services must release independently 15
  16. 16. Backwards compatibility ● Insulates teams from each other at runtime ● Allows service owners to deploy on their own schedule without impacting clients 16
  17. 17. Boundaries Between Tiers ● Limit aggregation to the front tier ● Limit crosstalk in the back tier: “superblocks” 17
  18. 18. Boundaries Between Tiers 18
  19. 19. Java RPC ● Difficult to maintain backwards compatibility ● Verb-centric APIs ● Use case specific APIs ● Difficult to navigate the proliferation of APIs 19
  20. 20. Rest.li plus Deco equals Microservices at LinkedIn
  21. 21. 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
  22. 22. Why Rest.li? ● Polyglot (frontend) ecosystem - Java, Scala, Python, Node.js, Objective-C ● Uniform service interfaces (REST) 22
  23. 23. The Rest.li stack Rest.li Data layer and RESTful operations D2 Dynamic discovery and load balancing R2 Network Communication 23
  24. 24. 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
  25. 25. Dynamic Discovery (D2) ● Apache ZooKeeper ● Dynamic server discovery ● Client side software load balancing ● D2 service Rest.li R2 D2 25
  26. 26. 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
  27. 27. 830 Rest.li resources. 90 billion Rest.li calls/day across multiple datacenters. 65% service-to-service calls.
  28. 28. What is deco? 28
  29. 29. 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
  30. 30. What is Deco? ● URN resolution library ● What data you want, not how you want it Time 1 2 3 30
  31. 31. Deco Example: Influencer Post Dummy Post by Karan Parikh at LinkedIn Hi QCon! /influencerPosts /influencerPosts /companies /profiles 31
  32. 32. Deco Example: Influencer Post deco://influencerPosts/123?projection=(title, content, author~(firstName, lastName, company~(companyName))) 32
  33. 33. Three services. One client call. Deco.
  34. 34. Rest.li plus Deco equals Microservices at LinkedIn
  35. 35. 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
  36. 36. How Deco enables Microservices ● Deals with service explosion ● Abstracts away services from clients 36
  37. 37. Challenges ● Coordinating a massive engineering effort. (LiX to the rescue!) ● Ensuring uniform RESTful interfaces ● Performance Rest.li API Hub37
  38. 38. Wins ● All languages talk to the same service ● Developer productivity ● Reduction of hardware load balancers ● Ability to expose APIs directly to third parties 38
  39. 39. LinkedIn Microservices
  40. 40. Questions?
  41. 41. 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
  42. 42. Watch the video with slide synchronization on InfoQ.com! http://www.infoq.com/presentations/linkedin- microservices-urn

×