This talk describes several common challenges of software systems at scale: * How to break up a monolithic application or a monolithic database into microservices. * How to approach shared data, joins, and transactions in a microservices ecosystem

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