Un monolithe microservices ready™ – BreizhCamp 2018

La vidéo est disponible sur la chaine youtube du Breizhcamp : https://www.youtube.com/watch?v=F8C_iPGhHoI.

Nous entendons beaucoup parler de microservices comme architecture pour développer nos applications. Malheureusement cette architecture est souvent approchée comme un objectif d’architecture logicielle, ce qui amène, à découper le logiciel dès sa création comme une série de livrable indépendant.

Et même si cette approche apporte de nombreux bénéfices, en ce qui concerne le développement et la scalabilité de la solution, elle vient aussi avec d’importantes contraintes qui peuvent complexifier le démarrage du projet.

Après une présentation de cette approche, avec ses avantages, mais aussi les inconvénients qu’elle amène. Je vous propose de renverser la logique qui consiste à créer un projet sous forme de microservices, en voyant comment développer un « monolithe » classique, tout en gardant ouvertes les options permettant le découpage futur du logiciel sous forme de microservices.

Sous forme d’un retour d’expérience sur comment nous créons des logiciels capables de supporter d’importantes charges, cette présentation fournit les concepts derrière la création d’applications fortement découplées pouvant être déployées « à la carte ».

Transcript

1. Monolith Microservices ready™ @Lilobase
2. accidental mandatory Complexity essential
3. Coupling Module complexity Module complexity Module complexity X X
4. Complexity is non-linear Complexity System size
5. Distributed doghouse
6. -Simon Brown « If you can’t build a monolith, what makes you think micro-services are the answer ? »
7. Monolith Microservices -Alvaro Sanchez
8. -Melvin Conway « organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations »
9. -Simon Brown
10. The problem has never been the monolith, but having a single coupled model
11. Multiple models lives in your application Invoice Catalog Payment Product Product Product This is not the same product
12. The primary coupling in software architecture is when concepts from separate contexts are entangled
13. Software architecture is about boundaries Boundaries between business domain contexts are semantic boundaries. These boundaries are crossed when concepts with the same name have different meaning and/or purpose.
14. Software architecture is about boundaries Collaborators with the same lifecycle should be persisted as a single unit Collaborators with different lifecycle shouldn’t be coupled at the persistence level (which mean no join between them)
15. Multiple models lives in your application Invoice Catalog Payment Product Product Product
16. We usually don’t get our models right on the first try. This is where having a single code base & deployment unit helps with the requested refactoring
17. « Two micro services and their shared database » -Mathias Verraes
18. implicit couplings are the root of all evil Most of the Implicit couplings comes from shared data sources
19. Messages brokers are also datasources
20. -Cyrille Dupuydauby « Years of fight against ‘DB as a MoM’ anti- pattern have finally paid off: I am now fighting against ‘MoM as a DB’ anti-pattern. »
21. Events are not created equal Invoice Catalog Payment Inventory
22. All events shouldn’t be globally broadcasted Invoice Catalog Payment Inventory
23. Align team with context Invoice Catalog Payment Inventory Team B Team A
24. Consumer / producer relationship
25. The micro services iceberg
26. -Graham Lea « They can be hard to see, and they can sink your app »
27. Distributed transaction
28. The saga pattern
29. A time bomb for the optimists
30. Dependencies, even more chances to get failures
31. Fault tolerance Circuit-breaker, rate-limiter, automatic retrying with exponential backoff, response caching, … Hystrix, Resilience4j
32. accidental mandatory Complexity essential
33. Micro-services are a deployment option
34. Going further • Applying the Saga Pattern • Caitie McCaffrey • Distributed Transactions: The Icebergs of Microservices • Graham Lea • Application Resilience Engineering & Operations at Netflix • Ben Christensen • arpinum/alexandria-api