Patterns of evolution from monolith to microservices

© 2021 Thoughtworks | Confidential
Patterns of
evolution from
monolith to
microservices

© 2021 Thoughtworks | Confidential 2
Sounds familiar?
● Does a small changes imply a new build that takes a lot of time?
● Does solving an incident of a business context interrupt
development related to a different context?
● With the increase in the size of the code repo, has it become
more complicated to keep the modules independent and
contribute to the codebase?
● Is expensive and hard to scale the application because it implies
a replication of a heavy process?
● Outdated dependencies requires a heavy maintenance effort?
Probably you are
facing the
challenges of a
overweight
monolith

Are you considering to move to microservices?
or began already your journey of evolution?
3

Karina Mora
Tech Principal at Thoughtworks, with a 12-year track record in different
business contexts. I had played various roles such as: developer,
technical leader, architect and strategic advisor for Technological
Initiatives, the role I currently play.
Passionate about consulting at the strategy level, as well as being an
active part in building the vision of teams that enable strategic initiatives.
I am interested in topics related to security, cloud architecture, and
technology platforms such as: OAuth and OpenIdConnect protocols, API
Management, APIOps, Service Mesh, and Cloud architectures with
Kubernetes.
I enjoy blending technology with business, meaning understanding the
technical details of architecture solutions, communicating them at
different levels of detail, and working closely with business roles to
connect technology decisions with business needs and priorities.
4

What is a microservice?

What is a microservice?
● Encapsulates one functionality in one
process and corresponding
independent service
● Changes of that functionality can scale
independently
6

Sounds good…there is a clear advantage
7

Why not start directly with
microservices?

Defining the limits of each service
9
Going straight to a microservices
architecture is risky
A monolith allows us to know
the complexity of a system as
well as the limits of its
components As complexity increases,
microservices can be extracted
You can continue to
extract
microservices as
new boundaries are
discovered and the
complexity of
managing the
monolith increases

What conditions do
microservices require?

Requirements for using
microservices
11
Requirements for
using
microservices
Ability to
deploy quickly
Monitoring
Rapid Provisioning
Capability
DevOps Culture
All of this
requirements
implies
having
Implementing a microservice-oriented
architecture without having automation for
testing or deployment is equivalent to
building a building without having built the
necessary foundations

Principles followed by microservices
12
Belongs to a
business domain
It is highly
observable
Isolate the faults
It is deployed
independently
Decentralize all the
things
Hide implementation
details
Has automation
Microservices
principles

How to start with the evolution?

Referred Domain Driven Design concepts
14
© 2021 Thoughtworks
Model Context
Bounded
context
Ubiquitous
Language
Repository
Domain
Anticorruption
layer
A sphere of
knowledge or
activity
A system of
abstractions
that represent
specific
aspects of the
domain
The setting in
which a phrase
or word
appears and
which
determines its
meaning
An explicit
definition of
from and to
where a
definition of a
particular
model is
correctly
defined and
applicable
Common
understanding
of the
definition that
is shared by
business
experts and
technical team
Cross-context
communication
that ensures
the isolation of
the consumer
model from
concepts
irrelevant to its
context
Common
abstraction of
object
references for
decoupled
persistence of
domain entities

PATTERN
Repository with
ACL as a bridge to
legacy model
15

Step 1 - Select a context and a use case
16
Belongs to a
business domain
It is highly
observable
Isolate the failures
It is deployed
independently
things
Hide implementation
details
Has automation
Microservices
principles
Context Customer
Business
Logic
New customer
registration

things
Step 2 - Create the microservice
17
Belongs to a
business domain
It is highly
observable
things
Hide implementation
details
Has automation
Microservices
principles
Context
Service
Business
Logic
DB Adapter
Repository
Data
Customer
New customer
registration
without database
It is deployed
independently

things
Step 3 - Replace the database with a ACL
18
Context
Service
Business
Logic
Repository
Customer
New customer
registration
Translator
Monolith <->Customer
Coordinator
ACL
Data
Monolith
API
API
Belongs to a
business domain
It is highly
observable
It is deployed
independently
Hide implementation
details
Has automation
Microservices
principles

things
things
Step 4 - Synchronize the monolith and microservice
19
Belongs to a
business domain
It is highly
observable
It is deployed
independently
Hide implementation
details
Has automation
Microservices
principles
Context
Service
Business
Logic
Repository
Customer
New customer
registration
ACL
Data
Monolith
DB Adapter
Data
API
API
Coordinator
Queue
Queue
Event
Retrofit

PATTERN
Canary release for
incremental
substitution
20

Canary release
Rollout of functionalities based on
business impact.
Traffic is directed from a subset of
users to the new services (new
functionality), after ensuring that no
issues were introduced, it is possible
to move towards 100% traffic.
Belongs to a
business domain
It is highly
observable
It is deployed
independently
things
Hide implementation
details
Microservices
principles
Has automation

Step 1 - Redirect traffic to the microservice
ALB
Load balancer
Repositorio
ACL
Data
Monolith
API
Event
Retrofit
5% 95%
Customer
API

95%
5%
Step 2 - Increase traffic to the microservice
23
ALB
Load balancer
Repositorio
Data
Monolith
API
50% 50%
API
Customer
ACL
Event
Retrofit

50%
50% 0%
100%
Step 3 - Stop the traffic to the monolith
24
ALB
Balanceador de carga
Data
Monolith
API
ALB
Load balancer
Repositorio
API
Customer
ACL
Event
Retrofit

PATTERN
Strangle of the
monolith
25

Step 1 - Identify key contexts
26
Monolith
Data
API
API
API
What business functionalities...
● change more often?
● have priority to be brought into production more
frequently?
● are Core in the business?
● are strategic and can give me a competitive
advantage?

Data
27
Step 2 - Replace the contexts one by one
Monolith
API
API
API
Event
Retrofit
Event
Retrofit
ACL
Event
Retrofit
API
Payment
API
Customer
API
Offer
ACL
ACL

Let's not underestimate the cost of change
28
The strangle pattern:
● It seeks to reduce the risk of a more abrupt change such as creating a new
system from scratch that replaces the legacy (Big Bang cut-over rewrite)
● Deliver results incrementally by enabling more frequent releases
However, we must remember:
● A total monolith replacement can be a multi-year project
● It is essential to identify the key contexts and prioritize them
● When building an application it is better to design it to be throttled, the code
of today tends to become a legacy in the future.

A new functionality brings challenges
Monolith
Data
API
Payment
method
registration
API
Customer
API
Payment
Customer
Preferred
Payment
Method Update
Package/class
level
communication
within the
same process
Network level
communication
REST request
REST response
timeout
error
response
Customer
Preferred
Payment
Method Update
API

With the scale the challenges increase
API
API
API
API
API
API
API
API
API
API
API
API

And the capabilities that are
repeated service to service?

In a microservice
32
API
Customer
Traffic management
Retry rules
Security
Metrics generation
Tracing
They are not business
logic
Belongs to a
business domain
It is deployed
independently
Hide implementation
details
Microservices
principles
It is highly
observable
things
Has automation
But are indispensable
in the microservice

In a complete ecosystem
API
API
API
API
API
API
API
API
API
API
API
API

Service mesh
34
API
Customer
API
Payment
Customer
Preferred
Payment
Method Update
Infrastructure layer that
allows supporting
common capabilities in
communication between
microservices without
having to include them in
the code.
REST request
REST response
Payment
method
registration

Service mesh
35
Payment
method
registration
API
Customer
API
Payment
REST request
REST response
Traffic management
Retry rules
Security
Metrics generation
Tracing
Traffic management
Retry rules
Security
Metrics generation
Tracing
Consul client
Caches the certificates
for mTLS communication
Sidecar
Proxy
Sidecar
Proxy
Customer
Preferred
Payment
Method Update
Consul client
Consul follower
server
Consul leader
server
Consul follower
server
Infrastructure layer that
allows supporting
common capabilities in
communication between
microservices without
having to include them in
the code.

When to use service mesh?
36
● A service mesh is very useful for migration to cloud scenarios, especially
when migrating to container orchestration platform as Kubernetes or Nomad,
due to its pod model they support multiple options (Linkerd, Consul, Istio).
● Service mesh also prevents that the multiple teams usually involved in
microservices ecosystems, spend development time on ad-hoc resolution of
these common features.
● Consul provides a good transition by generating a service discovery central
registry that generates a layer that abstracts the details of hybrid scenarios
like on premise VMs to be moved to containers in cloud.

When to decide to start using
events?

PATTERN
APIs Composition
38

Step 1 - Create APIs composer
39
API
Payment
API
Customer
API
Order
APIs
Composer
API Gateway & Microservice
(Business Capability API)
R
E
S
T
re
q
u
e
s
t
R
E
S
T
re
s
p
o
n
s
e
R
E
S
T
r
e
q
u
e
s
t
R
E
S
T
r
e
s
p
o
n
s
e
REST request
REST response
Last orders
of a
customer
with
payment
information
used
Data
Last orders
of a
customer
with
payment
information
used
SELECT DISTINCT
c.*, o.*, p.* FROM
CUSTOMER c,
ORDER o,
PAYMENT p
WHERE c.id =
p.customer_id AND
c.id = ? AND
o.paid_date >= ?
Monolith
QUERY

Step 2 - Parallelize and order calls
40
API
Customer
API
Order
API
Composer
Monolito
Customer Order Payment
Last orders
of a
customer
with
payment
information
used
APIs
Composer
R
E
S
T
r
e
q
u
e
s
t
R
E
S
T
r
e
s
p
o
n
s
e
REST request
REST response
API
Payment
R
E
S
T
re
q
u
e
s
t
R
E
S
T
re
s
p
o
n
s
e

Unavailability problem with REST
41
Availability depends on the
availability of dependencies
In a synchronous communication,
there is coupling at runtime, which
is evidenced by latency and
availability.
We need resilience mechanisms
due to unavailability:
- Retries
- timeout
- Fallback responses
API
Customer
API
Order
APIs
Composer
R
E
S
T
r
e
q
u
e
s
t
R
E
S
T
r
e
s
p
o
n
s
e
REST request
REST response
API
Payment
R
E
S
T
re
q
u
e
s
t
R
E
S
T
re
s
p
o
n
s
e

PATTERN
Circuit breaker
with async
request/response
42

Circuit breaker
Avoid retrying an operation that is
likely to fail, allowing the flow to
continue with default responses
while the problem is resolved.
Upon detecting that the problem has
been resolved, it allows the operation
to be executed again normally.
CLOSED OPEN
HALF OPEN
success
retry for
failure
exceeds retries
success
restart
retries
failure
fallback
response

1 s
2 s
44
Timeout = 10 s
Retries = 2
Restart time = 2
Step 1 - Configure the thresholds
API
Customer
API
Loyalty
Account
APIs
composer
R
E
S
T
r
e
q
u
e
s
t
R
E
S
T
r
e
s
p
o
n
s
e
REST
request
REST
response
New
customer
registration
COMMAND
2
3
1
API
User
R
E
S
T
r
e
q
u
e
s
t
R
E
S
T
r
e
s
p
o
n
s
e
Response time:
12 s
22 s
Thresholds

Step 2 - Define fallback response
API
Customer
API
Loyalty
Account
APIs
composer
R
E
S
T
r
e
q
u
e
s
t
R
E
S
T
r
e
s
p
o
n
s
e
REST
request
REST
response
API
User
R
E
S
T
r
e
q
u
e
s
t
R
E
S
T
r
e
s
p
o
n
s
e
HTTP 424
New
customer
registration
COMMAND
2
3
1
Response time:
22 s

Step 3 - Complete the ﬂow asynchronously
API
Customer
API
Loyalty
Account
APIs
composer
R
E
S
T
r
e
q
u
e
s
t
R
E
S
T
r
e
s
p
o
n
s
e
REST
request
REST
response
API
User
R
E
S
T
r
e
q
u
e
s
t
R
E
S
T
r
e
s
p
o
n
s
e
Queue
4
New
customer
registration
COMMAND
Queue
2
3
1
Notify the client about the update
push

Is APIs composition enough?
47
● API composition is a simple pattern to implement and can be useful for many
scenarios, especially querying.
● API composition should be designed considering resilience mechanisms (such
as short circuit) and parallelism.
● The nature of the use case guides the decision of synchronous or
asynchronous communication.
● We must handle the user experience to handle the expectation of eventually
completing your need in the case of async.
● It is possible to have hybrid architectures.

When to go direct for events?

Saga
49
A saga is a sequence of local
transactions (each one local to its
microservice).
Similar to how a DB-level atomic
transaction (2PC) resolves data
consistency in a monolith, a saga
seeks to resolve data consistency in
transactions involving multiple
microservices.
C1
C2
Tn+1
Tn+2
...
Pivot transaction
Retriable
transaction
T1
T2
Compensable
transactions

PATTERN
Saga orchestrator
50

Compensable transactions
by default
enriched
Pivot transaction
Retriable transaction
Later states
created
queued
sent
failed
delivered
Saga orchestrator
51
API
API
Saga
orchestrator
Send
notification to
the client based
on their
preferences
COMMAND
API
Email
Sending
Whatsapp
Sending
SMS
Sending
Persistent object that
implements a state machine
and is responsible for
invoking each participant in
the saga
Queue
Queue
Queue Queue Queue Queue
API
Customer
NOTIFICACIÓN
notification
id Queue
Queue
push

PATTERN
Saga
choreography
52

Saga choreography
53
API
Customer
API
Loyalty
Account
Message broker
API
User
4
New client
registration
COMMAND
Queue
2
3
1
Queue Queue
user id
5
7
8
6 9
Distributed
coordination in which
each microservice
emits and consumes
events associated
with the transactions
of the saga
A messaging broker
in this pattern makes
it possible to
guarantee the
delivery of messages

Comparison
54
Orchestration
● Centralized decision making
● Asynchronous request/response
oriented saga
● The coordination logic is
composed of the invocation to
each participant, their response
events and the compensations
invoked by the orchestrator.
Choreography
● Distributed decision making
● Event oriented saga
● The coordination logic is
composed of events published by
each microservice plus the
handlers to consume them
implemented in each microservice
that must execute the
compensations

PATTERN
CQRS & event
sourcing
55

Concepts
56
CQRS
● Segregation of command and
consultation responsibilities.
● Use events to update a query
replica.
● It can be implemented with event
sourcing or with traditional
persistence.
Event sourcing
● Event driven persistence
● Event storage can act as a broker
● The business entity is persisted as
a sequence of state change
events.
● The last state is reconstructed
based on the events.

A real example
57
Data model for commands Data model for queries
Message broker
Order
Order History
Materialized view
POST
PUT
DELETE
COMMAND QUERY
GET
Events Events
It can be event
sourcing
Last orders of a
customer with
payment
information used

Trade offs
58
CQRS
● Useful when API composition is
inefficient for queries as it may
contain history of combined
entities from multiple
microservices.
● There is a cost associated with
replica storage.
● The materialized view is eventually
consistent.
Event sourcing
● It is convenient to use it in
choreography, since it eliminates
the need for translation from event
to persistence.
● Ensures the accuracy of audit trails.
● Simplifies queries based on change
history.
● Adds inherent complexity to the
architecture

Final thoughts

To keep in mind
60
● Not everything has to be microservices, it is necessary to understand the
need we currently have.
● We can have hybrid solutions, with synchronous and asynchronous
communication according to each use case.
● In this process of evolution there are multiple patterns that can help us.
● Each step we take made our architecture evolve, whether towards
microservices or events, generates value for us, solving problems that we
identify along the way, but introduces more complexity, that is why the
foundations of a DevOps Culture (Observability, Continuous Delivery,
Provisioning) are essential for this.

Questions
Karina Mora
Tech Principal Thoughtworks Chile
kmora@thoughtworks.com
61
Does this architecture evolution journey sound familiar to you?
Are you facing similar challenges?
Are you considering a event oriented architecture for your solution?

Patterns of evolution from monolith to microservices

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Patterns of evolution from monolith to microservices

Similar a Patterns of evolution from monolith to microservices (20)

Último

Último (20)

Patterns of evolution from monolith to microservices