Save 37% off PRO during our Black Friday Sale! »

Un monolithe microservices ready™ – BreizhCamp 2018

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 ».

Beb422437c1dfb5366f197919e41ac50?s=128

Arnaud LEMAIRE
PRO

March 30, 2018
Tweet

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