This document discusses strategies for migrating a monolithic application to microservices. It begins with an overview of decomposing a monolith and implementing new features as microservices. It then provides an example of extracting the delivery module from a monolithic food delivery application into its own delivery microservice. The example outlines the steps of splitting the code, extracting the relevant database tables, defining and deploying the new delivery service, integrating it with the monolith, and removing the old code. Finally, it discusses implementing a delayed delivery service as another example.

1. @crichardson
Decompose your monolith:
strategies for migrating to
microservices
Chris Richardson
Founder of Eventuate.io
Founder of the original CloudFoundry.com
Author of POJOs in Action and Microservices Patterns
@crichardson
chris@chrisrichardson.net
http://adopt.microservices.io
Copyright © 2020. Chris Richardson Consulting, Inc. All rights reserved

2. @crichardson
Presentation goal
How to incrementally refactor a
monolithic application to
microservices

3. @crichardson
About Chris
http://adopt.microservices.io

4. @crichardson
About Chris
https://microservices.io/book
40% discount with code
ctwdevnexus20

5. About Chris: microservices.io
Microservices pattern
language
Articles
Example code
Microservices Assessment
Platform

6. @crichardson
Agenda
Why microservices?
Overview of refactoring a monolith
Implementing new features as services
Extracting modules into services
Example: extracting the Delivery Service
Example: implementing the Delayed Delivery Service

7. @crichardson
+
Marketplace is volatile, uncertain, complex
and ambiguous
+
Businesses must innovate faster
Deliver software rapidly, frequently and reliably
Software

8. @crichardson
Monolithic architecture: -ilities
decline over time
Time
Maintainability
Testability
Deployability
Modularity
Evolvability
Size/
Complexity
-ilities required to be competitive
Risk of
disruption

9. The microservice architecture is
an architectural style
that structures an application as a
set of services*
Each microservice is:
• highly maintainable and testable
• loosely coupled
• independently deployable
• organized around business capabilities
• owned by a small team
*Start with one service per team until it becomes a problem

10. @crichardson
Process: Lean + DevOps/Continuous Delivery & Deployment
Organization: Small,
autonomous,
product teams
Architecture:
microservices
Testability
Deployability
Modularity
Modularity
Evolvability
Maintainability
Rapidly, frequently
and reliably delivery of
changes to long-lived
applications

11. @crichardson
Agenda
Why microservices?
Overview of refactoring a monolith
Implementing new features as services
Extracting modules into services
Example: extracting the Delivery Service
Example: implementing the Delayed Delivery Service

12. @crichardson
When to migrate to the
Microservice Architecture?

13. @crichardson
DON”T!
Anti-pattern: Magic pixie dust

14. @crichardson
Make the most of the
monolithic architecture
The monolithic architecture is not an anti-pattern
If software delivery is slow
Optimize development process
Improve deployment pipeline = more automation
Improve team autonomy
Modularize the monolith
Eliminate hand-offs and create cross functional teams
If technology stack is obsolete modernize to a new monolith
…

15. @crichardson
If and only if that is
insufficient* then consider
migrating to microservices
*Large, complex applications developed by a
(usually) large team that need to be delivered
rapidly, frequently, and reliably

16. @crichardson
How do you decompose your
big, scary monolithic application?
Monolith
Service?
Microservice architecture
Service
Service
Service

17. @crichardson
This is a variant of application
modernization

18. @crichardson
According to Randy Shoup:
“As Martin Fowler likes to say, the only
thing a Big Bang rewrite guarantees is a
Big Bang!”
Via @randyshoup

19. @crichardson
Best done incrementally!

20. @crichardson
Strangler
Application
http://www.martinfowler.com/bliki/StranglerApplication.html
Incrementally migrate
functionality
from
existing application
to
new (strangler)
application

21. @crichardson

22. @crichardson
Strangling the monolith
Monolith
Time
Monolith
Service
Monolith
Service
Service
Monolith
Service
Service
Service
Service
…. Monolith
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
….
Strangler application
The strangler application grows larger over time
The monolith shrinks over time
Service
Service
Service
Service
Service
Service
Service
Service
New
features

23. @crichardson
Module
Iteratively: Module => Service
Monolith Service
API Gateway
Request
Monolith
Module
Request

24. @crichardson
Iteratively: New feature = Service
Monolith Service
API Gateway
Request

25. @crichardson
Measuring success
Success != Number of Microservices
Improved metrics:
Reduced lead time
Increased deployment frequency
Reduced changed failure rate
Improvements in other -ilities
…
Anti-pattern:
Microservices as the goal

26. @crichardson
Repeat extracting
services until:
• Eliminated the
monolith
• Solved software
delivery problems
• Higher priority work
Monolith
Time
Monolith
Service
Monolith
Service
Service
Monolith
Service
Service
Service
Service
…. Monolith
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
….
Strangler application
The strangler application grows larger over time
The monolith shrinks over time
Years

27. @crichardson
What to extract?
Have the ideal microservice architecture in mind
Limited timeboxed architecture definition effort
But be prepared to revise as you learn more
Start with the modules that would give you the greatest return
on investment (ROI)

28. Cost vs. Benefit of extraction
Benefit
Solves a significant
problem
Velocity frequently
updated
Scalability Conflicting
resource requirements
…
Cost
Cost of changing the
monolith and adapting/
rewriting module
Difficulty in decoupling/
breaking dependencies
Need to participate in
sagas/compensating
transactions

29. @crichardson
Cost of decoupling: ∝ # inbound dependencies
FTGO
<<module>>
Module A
<<module>>
Module B
<<module>>
Module C
Ext. API
Ext. API
Ext. API
Easy
Difficult
0
1
2
Dependencies can determine ordering

30. @crichardson
Cost: transaction
management/Sagas
T1 C1
T2
T3
Monolith
Compensating
transaction
T1
T2
T3
Monolith
Service
Increasing Cost
Service

31. @crichardson
Extracting a service: cost vs.
Benefit
Benefit of extraction
Ease of extraction
High
HighLow
Low
Module B
Module A
Module CModule D
Module E

32. @crichardson
To learn more…
https://microservices.io/book
40% discount with
code ctwdevnexus20
Chapter 13https://microservices.io/refactoring/index.html
https://github.com/microservices-patterns/ftgo-monolith

33. @crichardson
Agenda
Why microservices?
Overview of refactoring a monolith
Implementing new features as services
Extracting modules into services
Example: extracting the Delivery Service
Example: implementing the Delayed Delivery Service

34. @crichardson
Let’s imagine you want to implement
a significant new feature….
The Law of Holes:
"if you find yourself in a hole, stop digging"
(https://en.m.wikipedia.org/wiki/Law_of_holes)
Stop making the monolith larger!

35. @crichardson
Implement new functionality as a
service
Monolith Service
Data integration glue
API Gateway
Request
Monolithic
database
Service
database
Code in service/monolith
that enables service to
access monolith’s data
Pristine
new
service

36. @crichardson
Service Monolith data integration glue:
API invocation
Monolith Service
Monolithic
database
Service
database
Invokes
Command/
Query

37. @crichardson
Service Monolith data integration glue:
replicate data for reading
Monolith Service
Monolithic
database
Service
database
Application events
DB replicationTables Replica
CDC Events

38. @crichardson
Service Monolith data
access options
Option Benefits Drawbacks
API call to
monolith
Simple
Works for writes and reads
Doesn’t efficiently support
complex queries
Replicate
data to
service
Supports complex queries
Only for reads
Cost/complexity of replication

39. @crichardson
Data replication options
Option Benefits Drawbacks
Application events
Easy to publish meaningful events
Decoupled
Requires code changes in monolith
Eventual consistency
Change data capture
CRUD Events
No code changes in monolith
Decoupled
Publishing non-CRUD event is tricky
Eventual consistency
Triggers that publish
CRUD events
Simple
No code changes in monolith
Decoupled
Triggers = yuck
Publishing non-CRUD event is tricky
Eventual consistency
Triggers that update
target DB
Simple
No code changes in monolith
ACID consistency
Triggers = yuck
Coupled to target DB
Other DB replication
mechanism, e.g. OGG
Simple
No code changes in monolith
Coupled to target DB
Eventual consistency

40. @crichardson
Agenda
Why microservices?
Overview of refactoring a monolith
Implementing new features as services
Extracting modules into services
Example: extracting the Delivery Service
Example: implementing the Delayed Delivery Service

41. @crichardson
Module service ...
Monolithic database
Module’s tables
Module
Monolith
Ext. API
Including slices
of tables

42. @crichardson
Define a two way “remotable”
interface
Monolithic database
Module’s tables
Module
Untangle
dependencies
Monolith
Ext. API
Modifying the
monolith is
tricky

43. @crichardson
Incrementally modify monolith
to invoke module via new API*
Module
Module
All writes - module/service owns its data
Ideally all reads - but can replicate changes back
*Branch by abstraction pattern

44. @crichardson
Transform the database schema
ORDER_ID STATE … DELIVERY_STATE COURIER_ID
… … … … …
ORDER_ID STATE … STATE COURIER_ID
… … … … …
ID
…
ORDERS table
ORDERS table DELIVERY table
Extract delivery service
Delivery management

45. @crichardson
Replicating data to reduce scope of
refactoring
ORDER_ID STATE … DELIVERY_STATE COURIER_ID
… … … … …
ORDER_ID STATE … STATE COURIER_ID
… … … … …
ID
…
COURIER_ID
…
ORDERS table
ORDERS table DELIVERY table
Replicate back
Read-only replica Extract delivery service

46. @crichardson
... Module service
Monolith
Service
Monolithic database
Module
Database
API Gateway
Request
Existing code or
rewrite
Ext. API
Bidirectional integration glue

47. @crichardson
Agenda
Why microservices?
Overview of refactoring a monolith
Implementing new features as services
Extracting modules into services
Example: extracting the Delivery Service
Example: implementing the Delayed Delivery Service

48. @crichardson
AS-IS architecture
FTGO
<<module>>
Order and Delivery Management
<<entity>>
Order
ORDER_ID STATE … DELIVERY_STATE COURIER_ID
… … … … …
Consumer
Courier
ORDER table
noteAvailable()
notePickedUp
noteDelivered()
…
Tangled code
and data
Want to
extract

49. @crichardson
AS-IS: tangled code
Order
deliveryTime
Courier
address
availability
…
Plan
Action
type
Line
Item
Address
delivery
Delivery
Management
assigned courier
delivery
Restaurant
name
address
…
OrderService
scheduleDelivery()

50. @crichardson

51. @crichardson
TO-BE design
Delivery Service
Restaurant
name
address
Courier
…
Delivery
DeliveryService
schedule()
reschedule()
cancel()
“Replica”
FTGO
monolith
Data integration glue
Order
Management
API
Plan
Action
type
Order
deliveryTime
Courier
availability
location
…
deliveryTime availability
location
name
name

52. @crichardson
AS-IS TO-BE: Overview of
extracting the Delivery Service
1. Split the code: convert delivery management code into a
module within the monolith
2.Split the database: define separate DB schema for delivery
management within the monolith
3.Define and deploy Delivery Service
4.Use the Delivery Service
5.Remove old code from monolith
Commit and deploy changes after each step

53. @crichardson
FTGO
<<module>>
Order Management
<<module>>
Delivery Management
<<entity>>
Order
ORDER_ID STATE … DELIVERY_STATE COURIER_ID
… … … … …
Consumer Courier
schedule()
ORDER table
<<entity>>
Delivery
Step #1 - Separate code
cancel()
reschedule()

54. @crichardson
Delivery Mgmt
Module
Restaurant
name
address
Courier
name
availability
location
Delivery
deliveryTime
Delivery
Service
schedule()
reschedule()
cancel()
Delivery
Controller
updateCourierLocation()
updateCourierAvailability()
Order
Service
Order Mgmt
Module
Order
Order table
Courier
Restaurant
Mapped to original
tables
Order Controller
updateCourierLocation()
updateCourierAvailability()
External
API
Integration
API
Shared
table

55. @crichardson
FTGO
<<module>>
Order
Management
<<module>>
Delivery
Management
<<entity>>
Order
Consumer
Courier
schedule()
<<entity>>
Delivery
ORDER_ID STATE … STATE COURIER_ID
… … … … …
ID
…
DELIVERY tableORDER table Extract table
Step #2 - Separate data
COURIER_ID
…
Replicate back!
Creates
Delivery

56. @crichardson
Defining the DELIVERY table
create table ftgo_delivery.delivery (…)
select …subset of columns…
from ftgo.orders
where assigned_courier_id is not null;
CREATE TRIGGER assigned_courier_id_updated
AFTER UPDATE
ON delivery
FOR EACH ROW
BEGIN
UPDATE ftgo.orders
SET assigned_courier_id = NEW.assigned_courier_id
where id = NEW.id;
END;;
Replicate assigned_courier back to ORDERS table

57. @crichardson
Delivery Service schemaFTGO schema
But it’s not just the DELIVERY table
COURIER
id
name
availability
COURIER
id
name
availability
…
COURIER_
ACTIONS
…
COURIER_
ACTIONS
….
RESTAURANT
id
name
address
RESTAURANT
id
name
address
…
Sync

58. @crichardson
Replicating the RESTAURANT
table
create table ftgo_delivery.restaurants
select …subset of columns…
from ftgo.restaurants
CREATE TRIGGER restaurant_created AFTER INSERT
ON ftgo.restaurants
FOR EACH ROW
BEGIN
INSERT INTO ftgo_delivery_service.restaurants(…)
…

59. @crichardson
FTGO
<<module>>
Order
Management
<<module>>
Delivery
Management
<<entity>>
Order
Consumer Courier
schedule()
<<entity>>
Delivery
ORDER_ID STATE …
STATE COURIER_ID… … …
… …
ID
…
DELIVERY table
ORDER table
Delivery Service
<<module>>
Delivery
Management
<<entity>>
Delivery
Step #3 - Define and deploy
new service

60. @crichardson
FTGO
<<module>>
Order
Management
<<module>>
Delivery
Management
<<entity>>
Order
Consumer Courier
schedule()
<<entity>>
Delivery
ORDER_ID STATE …
STATE COURIER_ID
… … …
… …
ID
…
DELIVERY tableORDER table
Delivery Service
<<module>>
Delivery
Management
<<entity>>
Delivery
Step #4 - Use service

61. @crichardson
Integration using asynchronous messaging
Delivery
Service
Delivery
Service
schedule()
reschedule()
cancel()
Delivery
Controller
Order
Service
FTGO
Order Controller
Delivery
Service
Proxy
schedule()
…
Command
Handlers
Schedule
command
message
Message
channel

62. @crichardson
FTGO
<<module>>
Order
Management
<<entity>>
Order
Consumer Courier
schedule() Delivery Service
<<module>>
Delivery
Management
<<entity>>
Delivery
STATE COURIER_ID
… …
ID
…
DELIVERY table
ORDER_ID STATE …
… … …
ORDER table
Step #5 - delete old code

63. @crichardson
Agenda
Why microservices?
Overview of refactoring a monolith
Implementing new features as services
Extracting modules into services
Example: extracting the Delivery Service
Example: implementing the Delayed Delivery Service

64. @crichardson
FTGO Delayed delivery service
As a workaround for a mediocre
courier scheduling algorithm
that is taking too long to fix……
Improve customer satisfaction
by proactively notifying
customers (and customer
experience) that their order
won’t be delivered on time

65. FTGO Delayed delivery service
Periodically looks for
orders that won’t be
delivered on time
Not picked up and
restaurant closed
Courier delayed
…
Notifies consumer
and CRM system
getDelayedOrders()
Notification
Service
CRM system
Send
apology
notification
create case
REST
API
???
Delayed Order Service
«stereotype»
Order
«entity»
Restaurant
«entity»
OpeningHours
«entity»
Notification
API gateway
«repository»
Customer
ContactInfo
Repository
Monolith
???
REST
API
«Service»
DelayedDelivery
Service
Integration glue
Need to design

66. @crichardson
Delayed delivery service: data
integration strategies
Usage How
Orders
“complex” query to
determine whether
delivery will be
delayed
ReplicateRestaurants
Courier
Consumers
Contact info for
notifications
Query via API

67. @crichardson
Summary
The microservice architecture enables the rapid, frequent and
reliable delivery of changes to long-lived applications
Incrementally migrate to microservices when you have
outgrown your monolith
Implement new features as services
Extract modules into service
Prioritize extracting modules that give the greatest benefit

68. @crichardson
@crichardson chris@chrisrichardson.net
http://adopt.microservices.io
Questions?
40% discount with code
ctwdevnexus20