MONOLITH TO SERVICESHistory of a pattern based transition

Patrice Fricard - TechnicalArchitect

MONOLITH TO SERVICE: THE GENESIS

DAY 1:A simple business requirement is developed with different layer

DAY 2:We add new features keeping the good practices

DAY 5:The monster is born-hard to enhance functionally-hard to test-hard to upgrade technically

DAY 3:We add more and more features coupling layers

DAY 4:We take shortcuts to achieve go faster: no more layers

Any resemblance to real projects is purely coincidental.

MONOLITH TO SERVICE: PREPARATION PHASE

HOW TO HUNT THE BEAST

« every battle is won before it is fought »

• KNOW YOUR ENEMY

• PREPARE YOUR WEAPONS

• APPLY YOUR STRATEGY

Texte ici

THE CLOUD PATTERNS: THE MICROSERVICES ALLIES

Ambassador Valet Key

Throttling

Strangler

Command and Query Responsibility Segregation (CQRS)

Gateway Aggregation

Gateway Offloading

Gateway Routing

Gatekeeper

Health Endpoint Monitoring

Federated Identity

External Configuration StoreIndex Table

Leader ElectionMaterialized View

Queue-Based Load Leveling

Priority Queue

Pipes and Filters

Static Content Hosting

Sidecar

Scheduler Agent Supervisor

Sharding

Event Sourcing

Compute Resource Consolidation

Competing ConsumersCompensating Transaction

Circuit Breaker

Cache-Aside

Bulkhead

Backends for Frontends

Anti-corruption Layer

Retry

Microsoft Cloud Design Patterns

MONOLITH TO SERVICE: STRANGLER PATTERN

STRANGLE THE BEAST

• Stop digging / Starving the beast

• Split front end & back end

• Extract Modules

STRANGLER PATTERN« Incrementally migrate a legacy system by gradually replacing specific pieces of functionality

with new applications and services. As features from the legacy system are replaced, the new

system eventually replaces all of the old system's features, strangling the old system and

allowing you to decommission it. »

https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler

https://www.martinfowler.com/bliki/StranglerApplication.html

MONOLITH TO SERVICE ANTI-CORRUPTION LAYER PATTERN

ISOLATE THE BEAST

Put your legacy in a well defined zone

• ANTI -CORRUPTION LAYER PATERN

• between legacy and new services

• between legacy and downstream application

Texte ici

ASK YOU THE RIGHT QUESTION NOW

MONOLITH TO SERVICE: TRANSITION WAY

• HAVE WE AUTONOMOUS MODULES?

• Yes, so we can extract & refactor code in a service

• IS THE DATA MODEL FUNCTIONALLY CONSISTENT?

• No, you will have to send data to new service and legacy :(

• IS THE LEGACY FEEDING MULTIPLE DOWNSTREAM APPLICATION?

• Yes, rewrite with synchronization by replication

• No, rewrite with synchronization by aggregation

Texte ici

DETAILS OF THE « SYNCHRONISATION BY AGGREGATION »

MONOLITH TO SERVICE: TRANSITION WAY

UI

GatewayRouting

Legacy

GatewayAggregation

NewServic

e

• USE OF ONE AGGREGATION GATEWAY and ONE ROUTING

GATEWAY

• GOOD SCENARIO

• no data duplication

• separation of responsibility

Texte ici

DETAILS OF THE « SYNCHRONISATION BY REPLICATION »

MONOLITH TO SERVICE: TRANSITION WAY

UI

GatewayRouting

LegacyNew

Service

• USE OF ONE ROUTING GATEWAY

• WE DIDN’T HAVE TO MODIFY THE DOWNSTREAM FEEDING

Texte ici

DETAILS OF THE DOUBLE FEEDING SCENARIO

MONOLITH TO SERVICE: TRANSITION WAY

UI

Gateway Aggregation& Routing

Legacy

GatewayAggregation

NewServic

e

• USE OF A DOUBLE AGGREGATION GATEWAY

• TECHNICALLY COMPLEX

• WE DID’NT HAVE TO TOUCH THE LEGACY

Texte ici

INSURE THE DATA CONSISTENCY

MONOLITH TO SERVICE: TRANSITION WAY

UI

Gateway Aggregation& Routing

Legacy

GatewayAggregation

NewServic

e

• SIDECAR PATTERN

• we extended this pattern through a messaging bus

• but you can host it directly with your gatewaySIDECAR Consistency Check

Strangler is the key pattern

Ask you the 3 questions to find the best way

Not modifying the legacy is (y)our challenge