• Presentation from Sam Newman

Evolutionary architecture

  • Comment découper le monolithe
* Commencer par un petit service avec peu de contact (ne pas pas prendre un gros service comme les Notifications par ex)

Il faut apprendre de chaque extaction

First, Identify good first microservisce candidates
Dont’ have maniy ingoud

Ease of Decomposition vs Benefits of decomposition
You need to know what youare trying to achieve

Code that change frequently
Also check you backlog

Why

  • To to to market more quicly
  • For Scale
    • Identify you bottlenecks

Classify or prioritize
Benefit / Easier to Extract

Code duplications

  • Library but can have different version of this library in production
  • SErvice for common code

Incremental Change (NO BIG BANG REWRITE)

“If you do a big bang rewrite, the only thing you’re certain of is a big bang” - Martin Fowler (paraphrased)

Un big bang ne permet pas de livrer des nouveaux features, donc le mieux est d’associer les 2
Livrer toujours des nouveaux features mais avec des changements architecturaux
Decouper en petits morceaux

Where to Start
Microservices don’t seem to fit with on-premise deployment.

Hard to change : Small change need to deploy all the solution
TODO : Incremental migration (better decomposition)
Il est préféreable de faire des petites décompositions (sortir un service du monolithe), plutot qu’un gros big bang ou une réécriture

Application migration patterns

Database migration patterns

References

Book