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.

of

Scaling Your Architecture with Services and Events Slide 1 Scaling Your Architecture with Services and Events Slide 2 Scaling Your Architecture with Services and Events Slide 3 Scaling Your Architecture with Services and Events Slide 4 Scaling Your Architecture with Services and Events Slide 5 Scaling Your Architecture with Services and Events Slide 6 Scaling Your Architecture with Services and Events Slide 7 Scaling Your Architecture with Services and Events Slide 8 Scaling Your Architecture with Services and Events Slide 9 Scaling Your Architecture with Services and Events Slide 10 Scaling Your Architecture with Services and Events Slide 11 Scaling Your Architecture with Services and Events Slide 12 Scaling Your Architecture with Services and Events Slide 13 Scaling Your Architecture with Services and Events Slide 14 Scaling Your Architecture with Services and Events Slide 15 Scaling Your Architecture with Services and Events Slide 16 Scaling Your Architecture with Services and Events Slide 17 Scaling Your Architecture with Services and Events Slide 18 Scaling Your Architecture with Services and Events Slide 19 Scaling Your Architecture with Services and Events Slide 20 Scaling Your Architecture with Services and Events Slide 21 Scaling Your Architecture with Services and Events Slide 22 Scaling Your Architecture with Services and Events Slide 23 Scaling Your Architecture with Services and Events Slide 24 Scaling Your Architecture with Services and Events Slide 25 Scaling Your Architecture with Services and Events Slide 26 Scaling Your Architecture with Services and Events Slide 27 Scaling Your Architecture with Services and Events Slide 28 Scaling Your Architecture with Services and Events Slide 29 Scaling Your Architecture with Services and Events Slide 30 Scaling Your Architecture with Services and Events Slide 31 Scaling Your Architecture with Services and Events Slide 32 Scaling Your Architecture with Services and Events Slide 33 Scaling Your Architecture with Services and Events Slide 34 Scaling Your Architecture with Services and Events Slide 35 Scaling Your Architecture with Services and Events Slide 36 Scaling Your Architecture with Services and Events Slide 37 Scaling Your Architecture with Services and Events Slide 38 Scaling Your Architecture with Services and Events Slide 39 Scaling Your Architecture with Services and Events Slide 40 Scaling Your Architecture with Services and Events Slide 41 Scaling Your Architecture with Services and Events Slide 42 Scaling Your Architecture with Services and Events Slide 43 Scaling Your Architecture with Services and Events Slide 44 Scaling Your Architecture with Services and Events Slide 45 Scaling Your Architecture with Services and Events Slide 46 Scaling Your Architecture with Services and Events Slide 47 Scaling Your Architecture with Services and Events Slide 48 Scaling Your Architecture with Services and Events Slide 49
Upcoming SlideShare
What to Upload to SlideShare
Next
Download to read offline and view in fullscreen.

2 Likes

Share

Download to read offline

Scaling Your Architecture with Services and Events

Download to read offline

This session is a deep dive into the modern best practices around asynchronous decoupling, resilience, and scalability that allow us to implement a large-scale software system from the building blocks of events and services, based on the speaker's experiences implementing such systems at Google, eBay, and other high-performing technology organizations. We will outline the various options for handling event delivery and event ordering in a distributed system. We will cover data and persistence in an event-driven architecture. Finally, we will describe how to combine events, services, and so-called 'serverless' functions into a powerful overall architecture. You will leave with practical suggestions to help you accelerate your development velocity and drive business results.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

Scaling Your Architecture with Services and Events

  1. 1. Scaling Your Architecture with Services and Events Randy Shoup WeWork Kraków, 15-17 May 2019
  2. 2. Background • VP Engineering at WeWork o Physical space as a service • VP Engineering at Stitch Fix o Software and data science in clothing retail • Director of Engineering for Google App Engine o World’s largest Platform-as-a-Service • Chief Engineer at eBay o Multiple generations of eBay’s infrastructure
  3. 3. Evolution to Microservices • eBay • 5th generation today • Monolithic Perl  Monolithic C++  Java  microservices • Twitter • 3rd generation today • Monolithic Rails  JS / Rails / Scala  microservices • Amazon • Nth generation today • Monolithic Perl / C++  Java / Scala  microservices @randyshoup linkedin.com/in/randyshoup
  4. 4. No one starts with microservices … Past a certain scale, everyone ends up with microservices
  5. 5. If you don’t end up regretting your early technology decisions, you probably over- engineered.
  6. 6. Services and Events • Migrating to Microservices • Using Microservices and Events
  7. 7. Services and Events • Migrating to Microservices o When and Why to Migrate o How to Migrate • Using Microservices and Events
  8. 8. Services and Events • Migrating to Microservices o When and Why to Migrate o How to Migrate • Using Microservices and Events
  9. 9. Microservices • Single-purpose • Simple, well-defined interface • Modular and independent • Isolated persistence (!) A C D E B @randyshoup linkedin.com/in/randyshoup
  10. 10. Microservice Architecture • Each unit is simple • Independent scaling and performance • Independent testing and deployment • “Optimal” technology stack • Security boundary • Multiple cooperating units • Exchange in-process for network latencies • More sophisticated deployment and monitoring tools • System-level complexity Pros Cons
  11. 11. Why Migrate? • Velocity o Time to market is constrained by coupling and lack of isolation in the monolith o Teams step on each others’ toes, and can no longer develop independently o Difficult for new engineers to be productive • Scaling o Vertical scaling of the monolith no longer works o Parts of the system need to scale independently of others
  12. 12. Why Migrate? • Deployment o Parts of the system need to deploy independently of others o Monolithic release is too slow, too complicated, too risky
  13. 13. Services and Events • Migrating to Microservices o When and Why to Migrate o How to Migrate • Using Microservices and Events
  14. 14. Extracting Microservices • Problem: Monolithic shared DB • Clients • Shipments • Items • Styles, SKUs stitchfix.com Styling app Warehouse app Merch app CS app Logistics app Payments service Profile service @randyshoup linkedin.com/in/randyshoup
  15. 15. Extracting Microservices • Decouple applications / services from shared DB • Clients • Shipments • Items • Styles, SKUs stitchfix.com Styling app Warehouse app Merch app CS app Logistics app Payments service Profile service @randyshoup linkedin.com/in/randyshoup
  16. 16. Extracting Microservices • Decouple applications / services from shared DB Styling app Warehouse app core_item core_sku core_client @randyshoup linkedin.com/in/randyshoup
  17. 17. Extracting Microservices • Step 1: Create a service Styling app Warehouse app core_item core_sku core_client client-service @randyshoup linkedin.com/in/randyshoup
  18. 18. Extracting Microservices • Step 2: Applications use the service Styling app Warehouse app core_item core_sku core_client client-service @randyshoup linkedin.com/in/randyshoup
  19. 19. Extracting Microservices • Step 2: Applications use the service Styling app Warehouse app core_item core_sku core_client client-service Do NOT stop here! ① All the problems of a distributed system ② All the problems of a shared database ③ None of the benefits of microservices  @randyshoup linkedin.com/in/randyshoup
  20. 20. Extracting Microservices • Step 3: Move data to private database Styling app Warehouse app core_item core_sku client-service core_client @randyshoup linkedin.com/in/randyshoup
  21. 21. Extracting Microservices • Step 4: Rinse and Repeat Styling app Warehouse app core_sku client-service core_client item-service core_item @randyshoup linkedin.com/in/randyshoup
  22. 22. Extracting Microservices • Step 4: Rinse and Repeat Styling app Warehouse app client-service core_client item-service core_item style-service core_sku @randyshoup linkedin.com/in/randyshoup
  23. 23. Extracting Microservices • Step 4: Rinse and Repeat Styling app Warehouse app client-service core_client item-service core_item style-service core_sku @randyshoup linkedin.com/in/randyshoup
  24. 24. Services and Events • Migrating to Microservices • Using Microservices and Events o Two Architectural Tools o Shared Data o Joins o Transactions
  25. 25. Services and Events • Migrating to Microservices • Using Microservices and Events o Two Architectural Tools o Shared Data o Joins o Transactions
  26. 26. System of Record • Single System of Record o Every piece of data is owned by a single service o That service is the canonical system of record for that data • Every other copy is a read-only, non-authoritative cache @randyshoup linkedin.com/in/randyshoup customer-service styling-service customer-search billing-service
  27. 27. Events are First-Class • “A significant change in state” o Statement that some interesting thing occurred • Traditional 3-tier system o Presentation  interface / interaction o Application  stateless business logic o Persistence  database • Fourth fundamental building block o State changes  events o 0 | 1 | N consumers subscribe to the event, typically asynchronously @randyshoup linkedin.com/in/randyshoup
  28. 28. Microservices and Events • Events are a first-class part of a service interface • A service interface includes o Synchronous request-response (REST, gRPC, etc) o Events the service produces o Events the service consumes o Bulk reads and writes (ETL) • The interface includes any mechanism for getting data in or out of the service (!) @randyshoup linkedin.com/in/randyshoup
  29. 29. Services and Events • Migrating to Microservices • Using Microservices and Events o Two Architectural Tools o Shared Data o Joins o Transactions
  30. 30. Shared Data • Monolithic database makes it easy to leverage shared data • Where does shared data go in a microservices world? @randyshoup linkedin.com/in/randyshoup
  31. 31. Shared Data Option 1: Synchronous Lookup o Customer service owns customer data o Fulfillment service calls customer service in real time fulfillment-service customer-service @randyshoup linkedin.com/in/randyshoup
  32. 32. Shared Data Option 2: Async event + local cache o Customer service owns customer data o Customer service sends address-updated event when customer address changes o Fulfillment service caches current customer address fulfillment-servicecustomer-service @randyshoup linkedin.com/in/randyshoup
  33. 33. Shared Data Option 3: Shared metadata library o Read-only metadata, basically immutable o E.g., size schemas, colors, EU countries, US states, etc. receiving-serviceitem-service style-service @randyshoup linkedin.com/in/randyshoup
  34. 34. Services and Events • Migrating to Microservices • Using Microservices and Events o Two Architectural Tools o Shared Data o Joins o Transactions
  35. 35. Joins • Monolithic database makes it easy to join tables • Splitting the data across microservices makes joins very hard @randyshoup linkedin.com/in/randyshoup SELECT FROM A INNER JOIN B ON …
  36. 36. Joins Option 1: Join in Client Application o Get a single customer from customer-service o Query matching orders for that customer from order-service Customers Orders order-history-page customer-service order-service @randyshoup linkedin.com/in/randyshoup
  37. 37. Joins Option 2: Service that “Materializes the View” o Listen to events from item-service, events from order-service o Maintain denormalized join of items and orders together in local storage Items Order Feedback item-feedback-service item-service order-feedback-service @randyshoup linkedin.com/in/randyshoup
  38. 38. Joins Many common systems do this • “Materialized view” in database systems • Most NoSQL systems • Search engines • Analytic systems @randyshoup linkedin.com/in/randyshoup
  39. 39. Services and Events • Migrating to Microservices • Using Microservices and Events o Two Architectural Tools o Shared Data o Joins o Transactions
  40. 40. Transactions • Monolithic database makes transactions across multiple entities easy • Splitting data across services makes transactions very hard @randyshoup linkedin.com/in/randyshoup BEGIN; INSERT INTO A …; UPDATE B...; COMMIT;
  41. 41. “In general, application developers simply do not implement large scalable applications assuming distributed transactions.” -- Pat Helland Life After Distributed Transactions: An Apostate’s Opinion, 2007
  42. 42. “Grownups don’t use distributed transactions” -- Pat Helland
  43. 43. Workflows and Sagas • Transaction  Saga o Model the transaction as a state machine of atomic events • Reimplement as a workflow • Roll back with compensating operations in reverse A B C A B C @randyshoup linkedin.com/in/randyshoup
  44. 44. Workflows and Sagas Many real-world systems work like this • Payment processing • Expense approval • Travel • Software development process @randyshoup linkedin.com/in/randyshoup
  45. 45. Intermediate States Model intermediate states as part of your interface • Payment started, pending, complete • Expense submitted, approved, paid • Feature developed, reviewed, deployed, released @randyshoup linkedin.com/in/randyshoup
  46. 46. Choreography No central coordinator o No central management of workflow state o State transitions entirely through events o Implicit “guarantees” for termination of the state machine @randyshoup linkedin.com/in/randyshoup Transport A B C
  47. 47. Orchestration Workflow coordinator o Coordinator maintains state of workflow, guarantees termination o Coordinator triggers state transitions o Events (optionally) signal transitions @randyshoup linkedin.com/in/randyshoup Payment A B C
  48. 48. Services and Events • Migrating to Microservices o When and Why to Migrate o How to Migrate • Using Microservices and Events o Two Architectural Tools o Shared Data o Joins o Transactions
  49. 49. Dziękuję bardzo! @randyshoup linkedin.com/in/randyshoup medium.com/@randyshoup
  • whilpert

    Jun. 9, 2020
  • TonyYao3

    May. 16, 2020

This session is a deep dive into the modern best practices around asynchronous decoupling, resilience, and scalability that allow us to implement a large-scale software system from the building blocks of events and services, based on the speaker's experiences implementing such systems at Google, eBay, and other high-performing technology organizations. We will outline the various options for handling event delivery and event ordering in a distributed system. We will cover data and persistence in an event-driven architecture. Finally, we will describe how to combine events, services, and so-called 'serverless' functions into a powerful overall architecture. You will leave with practical suggestions to help you accelerate your development velocity and drive business results.

Views

Total views

727

On Slideshare

0

From embeds

0

Number of embeds

108

Actions

Downloads

23

Shares

0

Comments

0

Likes

2

×