Managing Data in Microservices Randy Shoup @randyshoup - - PowerPoint PPT Presentation

▶
managing data in microservices
SMART_READER_LITE
LIVE PREVIEW

Managing Data in Microservices Randy Shoup @randyshoup - - PowerPoint PPT Presentation

Dec 08, 2023 451 likes •1.05k views

Managing Data in Microservices Randy Shoup @randyshoup linkedin.com/in/randyshoup Background VP Engineering at Stitch Fix o Combining Art and Science to revolutionize apparel retail Consulting CTO as a service o Helping

slide-1
SLIDE 1

Managing Data in Microservices

Randy Shoup @randyshoup linkedin.com/in/randyshoup

slide-2
SLIDE 2

Background

  • VP Engineering at Stitch Fix
  • Combining “Art and Science” to revolutionize apparel retail
  • Consulting “CTO as a service”
  • Helping companies scale engineering organizations and technology
  • Director of Engineering for Google App Engine
  • World’s largest Platform-as-a-Service
  • Chief Engineer / Distinguished Architect at eBay
  • Multiple generations of eBay’s infrastructure

@randyshoup linkedin.com/in/randyshoup

slide-3
SLIDE 3

Stitch Fix

@randyshoup linkedin.com/in/randyshoup

slide-4
SLIDE 4

Stitch Fix

@randyshoup linkedin.com/in/randyshoup

slide-5
SLIDE 5

Stitch Fix

@randyshoup linkedin.com/in/randyshoup

slide-6
SLIDE 6

Stitch Fix

@randyshoup linkedin.com/in/randyshoup

slide-7
SLIDE 7

Combining Art and [Data] Science

  • 1:1 Ratio of Data Science to Engineering
  • Almost 100 software engineers
  • Almost 100 data scientists and algorithm developers
  • Unique in our industry
  • Apply intelligence to *every* part of the business
  • Buying
  • Inventory management
  • Logistics optimization
  • Styling recommendations
  • Demand prediction
  • Humans and machines augmenting each other

@randyshoup linkedin.com/in/randyshoup

slide-8
SLIDE 8

Styling at Stitch Fix

Personal styling Inventory

@randyshoup linkedin.com/in/randyshoup

slide-9
SLIDE 9

Personalized Recommendations

Inventory Algorithmic recommendations Machine learning

@randyshoup linkedin.com/in/randyshoup

slide-10
SLIDE 10

Expert Human Curation

Human curation Algorithmic recommendations

@randyshoup linkedin.com/in/randyshoup

slide-11
SLIDE 11

How do we work, and why does it work?

slide-12
SLIDE 12

Modern Software Development

Practices Culture Technology Organization

slide-13
SLIDE 13

Modern Software Development

TDD and Continuous Delivery DevOps Microservices Small Teams

slide-14
SLIDE 14

Modern Software Development

TDD and Continuous Delivery DevOps Microservices Small Teams

slide-15
SLIDE 15

Small “Service” Teams

  • Teams Aligned to Business Domains
  • Clear, well-defined area of responsibility
  • Single service or set of related services
  • Cross-functional Teams
  • All skill sets needed to do the job
  • Depend on other teams for supporting services,

libraries, and tools

@randyshoup linkedin.com/in/randyshoup

slide-16
SLIDE 16

Modern Software Development

TDD and Continuous Delivery DevOps Microservices Small Teams

slide-17
SLIDE 17

Test-Driven Development

  • Tests help you go faster
  • Tests “have your back”
  • Development velocity
  • Tests make better code
  • Confidence to break things
  • Courage to refactor mercilessly
  • Tests make better systems
  • Catch bugs earlier, fail faster

@randyshoup linkedin.com/in/randyshoup

slide-18
SLIDE 18

“Do you have time to do it twice?” “We don’t have time to do it right!”

slide-19
SLIDE 19

Test-Driven Development

  • Do it right (enough) the first time
  • The more constrained you are on time and resources, the more important

it is to build solid features

  • Build one great thing instead of two half-finished things
  • Right ≠ Perfect (80 / 20 Rule)
  • è Basically no bug tracking system (!)
  • Bugs are fixed as they come up
  • Backlog contains features we want to build
  • Backlog contains technical debt we want to repay

@randyshoup linkedin.com/in/randyshoup

slide-20
SLIDE 20

Continuous Delivery

  • Most applications deployed multiple times per day
  • More solid systems
  • Release smaller units of work
  • Smaller changes to roll back or roll forward
  • Faster to repair, easier to understand, simpler to diagnose
  • Rapid experimentation
  • Small experiments and rapid iteration are cheap

@randyshoup linkedin.com/in/randyshoup

slide-21
SLIDE 21

Modern Software Development

TDD and Continuous Delivery DevOps Microservices Small Teams

slide-22
SLIDE 22

DevOps

  • End-to-end Ownership
  • Team owns service from design to deployment to retirement
  • Responsible for
  • Features
  • Quality
  • Performance
  • Operations
  • Maintenance

@randyshoup linkedin.com/in/randyshoup

slide-23
SLIDE 23

You Build It, You Run It.

  • - Werner Vogels
slide-24
SLIDE 24

Modern Software Development

TDD and Continuous Delivery DevOps Microservices Small Teams

slide-25
SLIDE 25

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

slide-26
SLIDE 26

First Law of Distributed Object Design: Don’t distribute your objects!

  • - Martin Fowler
slide-27
SLIDE 27

If you don’t end up regretting your early technology decisions, you probably over- engineered.

  • - me
slide-28
SLIDE 28

Microservices

  • Single-purpose
  • Simple, well-defined interface
  • Modular and independent

A C D E B

slide-29
SLIDE 29

Microservices are nothing more than SOA done properly.

  • - me
slide-30
SLIDE 30

Microservices

  • Single-purpose
  • Simple, well-defined interface
  • Modular and independent
  • Isolated persistence (!)

A C D E B

slide-31
SLIDE 31

Microservice Persistence

  • Approach 1: Operate your own data store
  • Store to your own instance(s) of {Postgres, MySQL, etc.}, owned and
  • perated by the service team
  • Approach 2: Use a persistence service
  • Store to your own schema in {Dynamo, RDS, Spanner, etc.}, operated as a

service by another team or by a third-party provider

  • Isolated from all other users of the service
  • è Only external access to data store is through

published service interface

@randyshoup linkedin.com/in/randyshoup

slide-32
SLIDE 32

Events as First-Class Construct

  • “A significant change in state”
  • Statement that some interesting thing occurred
  • 0 | 1 | N consumers subscribe to the event, typically asynchronously
  • Traditional 3-tier system
  • Presentation è interface / interaction
  • Application è stateless business logic
  • Persistence è database
  • Fourth fundamental building block
  • State changes è events

@randyshoup linkedin.com/in/randyshoup

slide-33
SLIDE 33

Events as First-Class Construct

  • Events represent how the real world works
  • Finance
  • Software development process
  • Any “workflow”

@randyshoup linkedin.com/in/randyshoup

slide-34
SLIDE 34

Microservices and Events

  • Events are a first-class part of a service interface
  • A service interface includes
  • Synchronous request-response (REST, gRPC, etc)
  • Events the service produces
  • Events the service consumes
  • Bulk reads and writes (ETL)
  • The interface includes any mechanism for getting

data in or out of the service (!)

@randyshoup linkedin.com/in/randyshoup

slide-35
SLIDE 35

Extracting Microservices

  • Problem: Monolithic shared DB
  • Clients
  • Shipments
  • Items
  • Styles, SKUs
  • Warehouses
  • etc.

stitchfix.com Styling app Warehouse app Merch app CS app Logistics app Payments service Profile service

@randyshoup linkedin.com/in/randyshoup

slide-36
SLIDE 36

Extracting Microservices

  • Decouple applications / services from shared DB
  • Clients
  • Shipments
  • Items
  • Styles, SKUs
  • Warehouses
  • etc.

stitchfix.com Styling app Warehouse app Merch app CS app Logistics app Payments service Profile service

@randyshoup linkedin.com/in/randyshoup

slide-37
SLIDE 37

Extracting Microservices

  • Decouple applications / services from shared DB

Styling app Warehouse app core_item core_sku core_client

@randyshoup linkedin.com/in/randyshoup

slide-38
SLIDE 38

Extracting Microservices

  • Step 1: Create a service

Styling app Warehouse app core_item core_sku core_client client-service

@randyshoup linkedin.com/in/randyshoup

slide-39
SLIDE 39

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

slide-40
SLIDE 40

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

slide-41
SLIDE 41

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

slide-42
SLIDE 42

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

slide-43
SLIDE 43

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

slide-44
SLIDE 44

Microservice Techniques: Shared Data

  • Problem
  • Monolithic database makes it easy to leverage shared data
  • Where does shared data go in a microservices world?

@randyshoup linkedin.com/in/randyshoup

slide-45
SLIDE 45

Microservice Techniques: Shared Data

  • Principle: Single System of Record
  • Every piece of data is owned by a single service
  • 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

slide-46
SLIDE 46

Microservice Techniques: Shared Data

  • Approach 1: Synchronous Lookup
  • Customer service owns customer data
  • Fulfillment service calls customer service in real time

fulfillment-service customer-service

@randyshoup linkedin.com/in/randyshoup

slide-47
SLIDE 47

Microservice Techniques: Shared Data

  • Approach 2: Async event + local cache
  • Customer service owns customer data
  • Customer service sends address-updated event when customer address

changes

  • Fulfillment service consumes event, caches current customer address

fulfillment-service customer-service

@randyshoup linkedin.com/in/randyshoup

slide-48
SLIDE 48

Microservice Techniques: Shared Data

  • Approach 3: Shared metadata library
  • Read-only metadata, basically immutable
  • E.g., size schemas, colors, fabrics, US States, etc.

receiving-service item-service style-service

@randyshoup linkedin.com/in/randyshoup

slide-49
SLIDE 49

Microservice Techniques: Joins

  • Problem
  • Monolithic database makes joins very easy
  • Splitting the data into separate services makes joins very hard

@randyshoup linkedin.com/in/randyshoup

slide-50
SLIDE 50

Microservice Techniques: Joins

  • Approach 1: Join in Client Application
  • Get a single customer from customer-service
  • Query matching orders for that customer from order-service
  • Best for single A, multiple Bs (1:N join)

A B

  • rder-history-page

customer-service

  • rder-service
slide-51
SLIDE 51

Microservice Techniques: Joins

  • Many common systems do this
  • Web application “mashup”

@randyshoup linkedin.com/in/randyshoup

slide-52
SLIDE 52

Microservice Techniques: Joins

  • Approach 2: “Materialize the View”
  • Listen to events from item-service and order-feedback-service
  • Maintain denormalized join of items and order feedback in local storage
  • Best for high cardinality A and B (M:N join)

Items Order Feedback

item-feedback-service

  • rder-feedback-service

item-service

slide-53
SLIDE 53

Microservice Techniques: Joins

  • Many common systems do this
  • Most NoSQL approaches
  • “Materialized view” in database systems
  • Search engines
  • Analytic systems
  • Log aggregators

@randyshoup linkedin.com/in/randyshoup

slide-54
SLIDE 54

Microservice Techniques: Workflows and Sagas

  • Problem
  • Monolithic database makes transactions across multiple entities easy
  • Splitting data across services makes transactions very hard

@randyshoup linkedin.com/in/randyshoup

slide-55
SLIDE 55

Microservice Techniques: Workflows and Sagas

  • Transaction è Saga
  • Model the transaction as a state machine of atomic events
  • Reimplement as a workflow
  • Roll back by applying compensating operations in

reverse

A B C D A B C D

@randyshoup linkedin.com/in/randyshoup

slide-56
SLIDE 56

Microservice Techniques: Workflows and Sagas

  • Many common systems do this
  • Payment processing
  • Expense approval
  • Any multi-step workflow

@randyshoup linkedin.com/in/randyshoup

slide-57
SLIDE 57

Microservice Techniques: Workflows and Sagas

  • Ideal use for Functions as a Service (“Serverless”)
  • Very lightweight logic
  • Stateless
  • Triggered by an event

A B C D A B C D

ƛ ƛ ƛ ƛ ƛ ƛ ƛ ƛ

@randyshoup linkedin.com/in/randyshoup

slide-58
SLIDE 58

Modern Software Development

TDD and Continuous Delivery DevOps Microservices Small Teams

slide-59
SLIDE 59

Thanks!

  • Stitch Fix is hiring!
  • www.stitchfix.com/careers
  • Based in San Francisco
  • Hiring everywhere!
  • More than half remote, all across US
  • Application development, Platform engineering,

Data Science

  • Please contact me
  • @randyshoup
  • linkedin.com/in/randyshoup