Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
MONOLITH TO SERVICES
History 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 ...
MONOLITH TO SERVICE: PREPARATION PHASE
HOW TO HUNT THE BEAST
« every battle is won before it is fought »
• KNOW YOUR ENEMY...
Texte ici
THE CLOUD PATTERNS: THE MICROSERVICES ALLIES
Ambassador Valet Key
Throttling
Strangler
Command and Query Respons...
MONOLITH TO SERVICE: STRANGLER PATTERN
STRANGLE THE BEAST
• Stop digging / Starving the beast
• Split front end & back end...
MONOLITH TO SERVICE ANTI-CORRUPTION LAYER PATTERN
ISOLATE THE BEAST
Put your legacy in a well defined zone
• ANTI -CORRUPT...
Texte ici
ASK YOU THE RIGHT QUESTION NOW
MONOLITH TO SERVICE: TRANSITION WAY
• HAVE WE AUTONOMOUS MODULES?
• Yes, so we ca...
Texte ici
DETAILS OF THE « SYNCHRONISATION BY AGGREGATION »
MONOLITH TO SERVICE: TRANSITION WAY
UI
Gateway
Routing
Legacy
...
Texte ici
DETAILS OF THE « SYNCHRONISATION BY REPLICATION »
MONOLITH TO SERVICE: TRANSITION WAY
UI
Gateway
Routing
Legacy
...
Texte ici
DETAILS OF THE DOUBLE FEEDING SCENARIO
MONOLITH TO SERVICE: TRANSITION WAY
UI
Gateway
Aggregation
& Routing
Lega...
Texte ici
INSURE THE DATA CONSISTENCY
MONOLITH TO SERVICE: TRANSITION WAY
UI
Gateway
Aggregation
& Routing
Legacy
Gateway
...
Strangler is the key pattern
Ask you the 3 questions to find the best way
Not modifying the legacy is (y)our challenge
Prochain SlideShare
Chargement dans…5
×

XebiCon'17 : Monolith to microservice, histoire d’une transformation centrée sur les patterns de transition - Patrice Fricard

156 vues

Publié le

CQRS with event sourcing; we’ve been living it for the past 3 years with 3 micro services in production using the Axon Framework

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

XebiCon'17 : Monolith to microservice, histoire d’une transformation centrée sur les patterns de transition - Patrice Fricard

  1. 1. MONOLITH TO SERVICES History of a pattern based transition Patrice Fricard - TechnicalArchitect
  2. 2. 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.
  3. 3. 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
  4. 4. 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 Election Materialized View Queue-Based Load Leveling Priority Queue Pipes and Filters Static Content Hosting Sidecar Scheduler Agent Supervisor Sharding Event Sourcing Compute Resource Consolidation Competing Consumers Compensating Transaction Circuit Breaker Cache-Aside Bulkhead Backends for Frontends Anti-corruption Layer Retry Microsoft Cloud Design Patterns
  5. 5. 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
  6. 6. 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
  7. 7. 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
  8. 8. Texte ici DETAILS OF THE « SYNCHRONISATION BY AGGREGATION » MONOLITH TO SERVICE: TRANSITION WAY UI Gateway Routing Legacy Gateway Aggregation New Servic e • USE OF ONE AGGREGATION GATEWAY and ONE ROUTING GATEWAY • GOOD SCENARIO • no data duplication • separation of responsibility
  9. 9. Texte ici DETAILS OF THE « SYNCHRONISATION BY REPLICATION » MONOLITH TO SERVICE: TRANSITION WAY UI Gateway Routing Legacy New Servic e • USE OF ONE ROUTING GATEWAY • WE DIDN’T HAVE TO MODIFY THE DOWNSTREAM FEEDING
  10. 10. Texte ici DETAILS OF THE DOUBLE FEEDING SCENARIO MONOLITH TO SERVICE: TRANSITION WAY UI Gateway Aggregation & Routing Legacy Gateway Aggregation New Servic e • USE OF A DOUBLE AGGREGATION GATEWAY • TECHNICALLY COMPLEX • WE DID’NT HAVE TO TOUCH THE LEGACY
  11. 11. Texte ici INSURE THE DATA CONSISTENCY MONOLITH TO SERVICE: TRANSITION WAY UI Gateway Aggregation & Routing Legacy Gateway Aggregation New Servic e • SIDECAR PATTERN • we extended this pattern through a messaging bus • but you can host it directly with your gatewaySIDECAR Consistency Check
  12. 12. Strangler is the key pattern Ask you the 3 questions to find the best way Not modifying the legacy is (y)our challenge

×