Randy Shoup discusses the evolution of software architecture from monoliths to microservices, emphasizing the importance of incremental migration strategies to avoid complications. He highlights the principles of microservices, such as single responsibility and well-defined interfaces, and outlines various techniques for handling shared data and transactions in a microservices environment. The document also provides practical steps for transitioning from monolithic applications to microservices while managing data at scale.

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

2. 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

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. No one starts with microservices
…
Past a certain scale, everyone
ends up with microservices

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

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

7. Microservices
• Single-purpose
• Simple, well-defined interface
• Modular and independent
A
C D E
B

8. Microservices are nothing
more than SOA done properly.
-- me

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

10. Migrating to
Microservices
Randy Shoup
@randyshoup
linkedin.com/in/randyshoup

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

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

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

14. 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

15. 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

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

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

18. 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

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

20. 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

21. 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

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

23. Extracting
Microservices
• Step 1: Create a service
Styling app Warehouse app
core_item
core_sku
core_client
client-service

24. Extracting
Microservices
• Step 2: Applications use the service
Styling app Warehouse app
core_item
core_sku
core_client
client-service

25. Extracting
Microservices
• Step 3: Move data to private database
Styling app Warehouse app
core_item
core_sku
client-service
core_client

26. Extracting
Microservices
• Step 4: Rinse and Repeat
Styling app Warehouse app
core_sku
client-service
core_client
item-service
core_item

27. Extracting
Microservices
• Step 4: Rinse and Repeat
Styling app Warehouse app
client-service
core_client
item-service
core_item
style-service
core_sku

28. Extracting
Microservices
• Step 4: Rinse and Repeat
Styling app Warehouse app
client-service
core_client
item-service
core_item
style-service
core_sku

29. Managing Data at Scale:
Microservices and Events
Randy Shoup
@randyshoup
linkedin.com/in/randyshoup

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

31. 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
@randyshoup linkedin.com/in/randyshoup

32. 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

33. Microservice Techniques:
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

34. Microservice Techniques:
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
@randyshoup linkedin.com/in/randyshoup
customer-service
styling-service
customer-search
billing-service

35. Microservice Techniques:
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
@randyshoup linkedin.com/in/randyshoup

36. Microservice Techniques:
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
@randyshoup linkedin.com/in/randyshoup

37. Microservice Techniques:
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

38. Microservice Techniques:
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 …

39. Microservice Techniques:
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

40. Microservice Techniques:
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

41. Microservice Techniques:
Joins
• Many common systems do this
o “Materialized view” in database systems
o Most NoSQL systems
o Search engines
o Analytic systems
@randyshoup linkedin.com/in/randyshoup

42. Microservice Techniques:
Workflows and Sagas
• 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;

43. Microservice Techniques:
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
@randyshoup linkedin.com/in/randyshoup

44. Microservice Techniques:
Workflows and Sagas
• Many common systems do this
o Payment processing
o Expense approval
o Travel
o Any multi-step workflow
@randyshoup linkedin.com/in/randyshoup

45. Microservice Techniques:
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
@randyshoup linkedin.com/in/randyshoup
ƛ ƛ ƛ
ƛ ƛ ƛ

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

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