Monoliths, Migrations, and Microservices

Monoliths, Migrations, and
Microservices
Randy Shoup
@randyshoup
linkedin.com/in/randyshoup

Background
• VP Engineering at WeWork
o Physical space as a service
• VP Engineering at Stitch Fix
o Combining “Art and Science” to revolutionize apparel retail
• Consulting “CTO as a service”
o Helping companies scale engineering organizations and technology
• Director of Engineering for Google App Engine
o World’s largest Platform-as-a-Service
• Chief Engineer / Distinguished Architect 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

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

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

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

Migrating to
Microservices
Randy Shoup
@randyshoup

Migrating to
Services
• Incremental Migration
• Migrating a Monolithic Application
• Migrating a Monolithic Database

“The only thing a Big Bang
migration guarantees is a big
*Bang*.”
-- Martin Fowler

Incremental
Migration
• Step 0: Pilot Implementation
o Choose initial end-to-end vertical experience to migrate / create
o (+) Opportunity to learn and adjust
o (+) Demonstrate feasibility and gain confidence
o (+) Bound investment and risk
o (+) Provide real customer value
• Initial step is the hardest
o Learning how to do things in the new way
o Building out basic supporting capabilities

Incremental
Migration
• Steps 1-N: Incremental Migration
o Prioritize business value -- highest ROI areas first
o Focus on areas with greatest rate of change
o (+) Maximize near-term payoff from investment
o (+) Confront and solve hard problems sooner rather than later
• New feature development in parallel
o Typically cannot pause all feature work in all areas to migrate 
o Within a particular area, try to separate feature work from migration work in
distinct steps

Incremental
Migration
• Residual monolith may remain indefinitely
o Lowest business value
o Most stable and least changing
o Can migrate – or not – opportunistically

Carving up the
Monolith
• Look for (or create) a “seam” in the
monolith
o This is often the hardest part (!)
• Wall it off behind an interface
• Write automated tests around the
interface
• Replace implementation with an
independent component
•  Rinse and Repeat

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

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

Extracting
Microservices
• Decouple applications / services from shared DB
Styling app Warehouse app
core_item
core_sku
core_client

Extracting
Microservices
• Step 1: Create a service
core_item
core_sku
core_client
client-service

Extracting
Microservices
• Step 2: Applications use the service
core_item
core_sku
core_client
client-service

Extracting
Microservices
• Step 3: Move data to private database
core_item
core_sku
client-service
core_client

Extracting
Microservices
• Step 4: Rinse and Repeat
core_sku
client-service
core_client
item-service
core_item

Extracting
Microservices
• Step 4: Rinse and Repeat
client-service
core_client
item-service
core_item
style-service
core_sku

Managing Data at Scale:
Microservices and Events
Randy Shoup
@randyshoup

With Microservices, how do
we do
• Shared Data
• Joins
• Transactions

Events as
First-Class Construct
• “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 (!)

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

Shared Data
• Principle: 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

Shared Data
• Approach 1: Synchronous Lookup
o Customer service owns customer data
o Fulfillment service calls customer service in real time
fulfillment-service
customer-service

Shared Data
• Approach 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
• Approach 3: Shared metadata library
o Read-only metadata, basically immutable
o E.g., size schemas, colors, fabrics, 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
• Approach 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
• Approach 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
o “Materialized view” in database systems
o Most NoSQL systems
o Search engines
o Analytic systems

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

Workflows and Sagas
• Transaction  Saga
o 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
A B C

Workflows and Sagas
• Many common systems do this
o Payment processing
o Expense approval
o Travel
o Any multi-step workflow

Workflows and Sagas
• Simple event-driven processing
o Very lightweight logic
o Stateless
o Triggered by an event
•  Consider Function-as-a-Service (“Serverless”)
A B C
A B C
ƛ ƛ ƛ
ƛ ƛ ƛ

Thank You!
• @randyshoup
• linkedin.com/in/randyshoup

Monoliths, Migrations, and Microservices

Recommended

More Related Content

What's hot (20)

Similar to Monoliths, Migrations, and Microservices (20)

More from Randy Shoup (20)

Recently uploaded (20)

Monoliths, Migrations, and Microservices