Scaling Your Architecture with Services and Events

Scaling Your Architecture
with Services and Events
Randy Shoup
WeWork
Kraków, 15-17 May 2019

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

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

No one starts with microservices
…
Past a certain scale, everyone
ends up with microservices

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

Services and Events
• Migrating to Microservices
• Using Microservices and Events

Services and Events
o When and Why to Migrate
o How to Migrate

Microservices
• Single-purpose
• Simple, well-defined interface
• Modular and independent
• Isolated persistence (!)
A
C D E
B

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

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

Why Migrate?
• Deployment
o Parts of the system need to deploy independently of others
o Monolithic release is too slow, too complicated, too risky

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

• 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

• 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 2: Applications use the service
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 

• 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

Services and Events
o Two Architectural Tools
o Shared Data
o Joins
o Transactions

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
customer-service
styling-service
customer-search
billing-service

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

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 (!)

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

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

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

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

Joins
• Monolithic database makes it easy to join tables
• Splitting the data across microservices makes joins very hard
SELECT FROM A INNER JOIN B ON …

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

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

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

Transactions
• Monolithic database makes transactions across multiple
entities easy
• Splitting data across services makes transactions very hard
BEGIN; INSERT INTO A …; UPDATE B...; COMMIT;

“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

“Grownups don’t use
distributed transactions”
-- Pat Helland

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

Workflows and Sagas
Many real-world systems work like this
• Payment processing
• Expense approval
• Travel
• Software development process

Intermediate States
Model intermediate states as part of your interface
• Payment started, pending, complete
• Expense submitted, approved, paid
• Feature developed, reviewed, deployed, released

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
Transport
A B C

Orchestration
Workflow coordinator
o Coordinator maintains state of workflow, guarantees termination
o Coordinator triggers state transitions
o Events (optionally) signal transitions
Payment
A B C

Services and Events
o When and Why to Migrate
o How to Migrate
o Two Architectural Tools
o Shared Data
o Joins
o Transactions

Dziękuję bardzo!
@randyshoup
linkedin.com/in/randyshoup
medium.com/@randyshoup

Scaling Your Architecture with Services and Events

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Scaling Your Architecture with Services and Events

Similaire à Scaling Your Architecture with Services and Events (20)

Plus de Randy Shoup

Plus de Randy Shoup (18)

Dernier

Dernier (20)

Scaling Your Architecture with Services and Events