Preliminary investment required before refactoring your monolith into microservices, and a series of steps, recipes and patterns to help you succeed when refactoring your application & your data into a microservices-style architecture.

1. REFACTORING INTO
MICROSERVICES
Ismael Rivera
Lead Software Engineer at Altocloud

2. MEETTHE MONOLITH
• A single codebase
• Hard to scale the application
• Impossible to scale the team

3. WHY MICROSERVICES?
• Modularity
• Separation of Concerns
• Single Responsibility Principle
• Business Agility
• Independently deployable

4. HOW DO I START?
• DevOps
• Service Discovery
• Monitoring
• Logging
• Testing strategy

5. REFACTORYOUR
APPLICATION
Big Ball of Mud? Stop!

6. REFACTORYOUR
APPLICATION
• Split front-end & back-end
Presentation layer (HTML)
Data Access Object
Business Logic
Browser
Database
Webapp
(HTML)
API
Browser
Database
DAO
Business Logic

7. REFACTORYOUR
APPLICATION
• Extract services
Order
Module
Fulfilment
Module
Payment
Module
...
Database
API Gateway
Order
Service
Fulfilment
Service
Payment
Service
Database
API
API
API

8. v1
v1
v1
REFACTORYOUR DATA
Database
Order
Service
Fulfilment
Service
Payment
Service
API
API
API
v2

10. –WernerVogels
“For us service orientation means encapsulating the
data with the business logic that operates on the data,
with the only access through a published service
interface. No direct database access is allowed from
outside the service, and there’s no data sharing
among the services.”

11. REFACTORYOUR DATA
Order
Service
Fulfilment
Service
Payment
Service
Database
API
API
API
Database Database

12. REFACTORYOUR DATA
Order
Service
Fulfilment
Service
Payment
Service
Database
API
API
API
Database Database SparkSpark

13. REFACTORYOUR DATA
Order
Service
Database
API
Payment
Service
API
Database Fulfilment
Service
API
Database
SparkSpark
Message
Broker
Fraud detection?
Stolen card
Stolen card

14. REFACTORYOUR DATA
• Forget ACID transactions
• Forget a single Enterprise Domain Model
• Forget Relational Integrity

15. REFACTORYOUR DATA
Order
Service
Fulfilment
Service
Database
API
API
Database Database
Payment
Service
API
tx tx tx

16. REFACTORYOUR DATA
Database
Database
Database
Payment
Service
API
Message
Broker
Order created
Order created
Payment received
Payment received
Order confirmed Order confirmed
Order shipped
Order shipped
Fulfilment
Service
API
Order
Service
API

17. REFACTORYOUR DATA
• Domain-Driven Design
Customers
Products OrdersCategories
Customers
Orders
Tickets Assignee
Address
Bounded Context
Bounded Context
Microservices is about boundaries and so is DDD.

18. REFACTORYOUR DATA
• Duplicate vs Pull
Order
Service
API
Email
Service
API
Payment
Service
API
Message
Broker
Pull
OrderOrder
Template
Publish
Subscribe
Publish

19. REFACTORYOUR DATA
id name email
1 Mark mark@email.com
2 John john@email.com
3 Siobhan siobhan@email.com
CUSTOMERS
id customer_id amount
1 2 125.33
2 3 77.81
ORDER
CREATE TABLE orders (
id INT PRIMARY KEY,
customer_id INT NOT NULL,
...
CONSTRAINT fk_inv_customer_id
FOREIGN KEY (customer_id)
REFERENCES customers (id)
ON DELETE CASCADE);
• Forget Relational Integrity

20. REFACTORYOUR DATA
id name email new_column
1 Mark mark@email.com
2 John john@email.com
3 Siobhan siobhan@email.co
m
ALTER TABLE ADD new_column VARCHAR(255);
Order
Service
API
[{
"id": 1,
"name": "Mark",
"email": "mark@email.com",
"new_column": "my default"
}, {
"id": 2,
...
}]
JSON

21. REFACTORYOUR DATA
• Strangler
Legacy
A
B
...
A
B
...
Legacy
Router Router

22. REFACTORYOUR DATA
• Branch by Abstraction
Legacy
Consumer
Legacy
Consumer
Abstraction Layer
Legacy New
Abstraction Layer
Consumer
New
Consumer
Abstraction Layer

23. REFACTORYOUR DATA
• CRUD
• Event-driven architecture
• CQRS (Command Query Responsibility Segregation)
• Event Sourcing

24. –Kent Beck
“Make the change easy, then make the easy change.”

25. TAKE-AWAYS
• Start small, look at this as an iterative problem.
• There isn't one right answer.
• Easier to scale.
• Failure will always happen.
• Don't over refactor.