effective microservices in a data-centric world · • best for high cardinality a and high...

Effective Microservicesin a Data-centric World

Randy Shoup @randyshoup

linkedin.com/in/randyshoup

Background• VP Engineering at Stitch Fix

o Revolutionizing retail by combining “Art and Science”

• Consulting “CTO as a service”o Helping companies scale their organizations and technology

• Director of Engineering for Google App Engineo World’s largest Platform-as-a-Service

• Chief Engineer at eBayo Multiple generations of eBay’s infrastructure

Stitch Fix

Combining Art and [Data] Science

• 1:1 Ratio of Data Science to Engineeringo >70 software engineerso >70 data scientists and algorithm developerso Unique in our industry?

• Apply intelligence to *every* part of the businesso Buyingo Inventory managemento Logistics optimizationo Styling recommendationso Demand prediction

• Humans and machines augmenting each other

Styling at Stitch Fix

Personal styling

Inventory

PersonalizedRecommendations

Inventory Algorithmic recommendations

Machine learning

Expert HumanCuration

Human curation

Algorithmic recommendations

How do we work, and why does it work?

Modern SoftwareDevelopment

Practices

CultureTechnology

Organization


TDD and Continuous

Delivery

DevOpsMicroservices

Small Teams

Small“Service” Teams

• Teams Aligned to Domainso Clear, well-defined area of responsibilityo Single service or set of related services

• Cross-functional Teamso Team has inside it all skill sets needed to do the job

• Depend on other teams for supporting services, libraries, and tools


TDD and Continuous

Delivery

DevOpsMicroservices

Small Teams

Test-Driven Development

• Tests help you go fastero Tests “have your back”o Development velocity

• Tests make better codeo Confidence to break thingso Confidence to refactor

• Tests make better systemso Catch bugs earlier, fail faster

Test-Driven Development

• “Don’t have time to do it right” ?o WRONG J – Don’t have time to do it twice (!)

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

it is to build solid featureso Right != perfect

• è Basically no bug tracking system (!)o Bugs are fixed as they come upo Backlog contains features we want to buildo Backlog contains technical debt we want to repay

ContinuousDelivery

• Most applications deployed multiple times per day

• More solid systemso Release smaller units of worko Faster to repair, easier to diagnoseo Smaller changes to roll back or roll forward

• Enables experimentationo Small experiments and rapid iteration are cheap


TDD and Continuous

Delivery

DevOpsMicroservices

Small Teams

DevOps• End-to-end Ownership

o Team owns service from design to deployment to retirement

• Responsible for o Featureso Qualityo Performanceo Operationso Maintenance

• “You build it, you run it!”


TDD and Continuous

Delivery

DevOpsMicroservices

Small Teams

Architecture Evolution

• 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

Microservices

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

A

C D E

B

Microservices are nothing more than SOA done properly.

-- me

Microservices

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

A

C D E

B

MicroservicePersistence

• Approach 1: Operate your own data storeo Store to your own instance(s) of {Postgres, MySQL, etc.}, owned and

operated by the service team

• Approach 2: Use a persistence serviceo Store to your own table(s) in {Dynamo, RDS, Spanner, etc.}, operated as a

service by another team or by a third-party providero Isolated from all other users of the service

• è Only external access to data store is through published service interface

Maintaining Interface Stability

• Backward / forward compatibility of interfaceso Can *never* break your clients’ code

• Semantic versioning (major.minor.patch)o Often multiple interface versionso Sometimes multiple deployments

• Explicit deprecation policy o Strong incentive to wean customers off old versions (!)

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


• 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


• Decouple applications / services from shared DB

Styling app Warehouse app

core_item

core_sku

core_client


• Step 1: Create a service


core_item

core_sku

core_client

client-service


• Step 2: Applications use the service


core_item

core_sku

core_client

client-service


• Step 3: Move data to private database


core_item

core_sku

client-service

core_client


• Step 4: Rinse and Repeat


core_sku

client-service

core_client

item-service

core_item


• Step 4: Rinse and Repeat


client-service

core_client

item-service

core_item

style-service

core_sku

Microservice Techniques:Shared Data

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

• Principle: Single System of Recordo Every piece of data is owned by a single serviceo That service represents its canonical system of recordo Every other copy of that data is a read-only, non-authoritative cache


• Approach 1: Synchronous Lookupo Customer service owns customer datao Order service calls customer service in real time

order-service

customer-service


• Approach 2: Async event + local cacheo Customer service owns customer datao Customer service sends customer-updated event when customer

changeso Order service caches current customer information

order-servicecustomer-service


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

receiving-serviceitem-service

style-service

Events asFirst-Class Construct

• “A significant change in state”o Statement that some interesting thing occurredo 0 | 1 | N consumers subscribe to the event, typically asynchronously

• Fourth fundamental building blocko Presentation è interface / interactiono Application è stateless business logico Persistence è databaseo State changes è events

• Events represent how the real world workso Finance, software development process, any “workflow”

Microservicesand Events

• Events are a first-class part of the interface

• A service interface includeso Synchronous request-response (REST, gRPC, etc)o Events the service produceso Events the service consumeso Bulk reads and writes (ETL)

• The interface includes any mechanism for getting data in or out of the service (!)

Microservice Techniques:Joins

• Problemo Monolithic database makes joins very easyo Splitting the data into separate services makes joins very hard


• Approach 1: Service that “Materializes the View”o Listen to events from item-service, events from order-serviceo Maintain denormalized join of items and orders together in local storage

• Best for high cardinality A and high cardinality B (M:N join)

Items Orders

item-feedback-serviceitem-serviceorder-service


• Many common systems do thiso Most NoSQL approacheso “Materialized view” in database systemso Search engineso Analytic systemso Log aggregators


• Approach 2: Join in Application / Cliento Get a single customer from customer-serviceo Query matching orders for that customer from order-service

• Best for single A, multiple Bs (1:N join)

AB

order-history-page

customer-service order-service


• Many common systems do thiso Web application “mashup”

Microservice Techniques:Workflows and Sagas

• Problemo Monolithic database makes transactions across multiple entities easyo Splitting data across services makes transactions very hard


• Transaction è Sagao 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


• Many common systems do thiso Payment processing flowo Most approval workflows


• Ideal use for Functions as a Service (“Serverless”)o Very lightweight logico Statelesso Triggered by an event

A B C D

A B C D

ƛ

ƛ

ƛ

ƛ

ƛ

ƛ

ƛ

ƛ


TDD and Continuous

Delivery

DevOpsMicroservices

Small Teams

Thanks!• Stitch Fix is hiring!

o www.stitchfix.com/careerso Application development, Platform engineering,

Data Scienceo Based in San Franciscoo More than half remote, all across US

• Please contact meo @randyshoupo linkedin.com/in/randyshoup

effective microservices in a data-centric world · • best for high cardinality a and high...

Documents