Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DevoxxFR 2022 : et si les micro services n'avai...

DevoxxFR 2022 : et si les micro services n'avaient rien à voir avec la technique ?

Encore une conférence sur les micro-services ? c'est tellement pre-pandémie comme sujet. 🤷‍♂️

Non, ce n'est pas une conf sur les micro-services. Enfin si... mais c'est pas pareil.

Ce dont on va parler c'est d'organisation, d'équipes, de communication, de topologie, de rôles, etc. Avec en exemple de nombreux changements qu'on a essayé, testé, implémenté chez Docker.

Alors peut-être qu'ensuite vous pourrez répondre à des questions du type "quelle taille doit faire un micro-service ?". Ou pas. Et d'ailleurs, tout ceci pourra s'appliquer même si vous ne faites pas de micro-services 🤗

Yves Brissaud

April 21, 2022
Tweet

More Decks by Yves Brissaud

Other Decks in Technology

Transcript

  1. Et si les micro-services n’avaient rien à voir avec la

    technique ? DevoxxFR 2022 Yves Brissaud @_crev_
  2. Yves Brissaud Senior Software Engineer @ Docker • Docker Hub

    • Vulnerability Scanning • Publisher experience: • Docker Official Images • Docker Verified Publishers • Docker sponsored Open Source Program @_crev_ @eunomie
  3. We are hiring! • https://www.docker.com/career-openings/ • DevoxxFR booth • Full

    remote • Backend, frontend, infrastructure, data, cloud database, … • Junior to senior
  4. Microservices vs Monolithes vs … “If you can’t build a

    monolith, what makes you think micro services are the answer?” 
 — Simon Brown “Start with monolith and extract micro services” 
 — Tammer Saleh “Don’t start with a monolith when your goal is a micro services architecture” 
 — Stefan Tilkov Micro service: something that could be rewritten in two weeks 
 — Jon Eaves
  5. Ce que vous ne trouverez pas ici • Outil, framework,

    … • Architecture • Caractéristique, taille, … • Docker, container, kubernetes, …
  6. Et si les micro-services avaient parfois à voir avec la

    technique ? • Besoin en ressources spécifique • Besoin en sécurité spécifique • Besoin technique spécifique • Métier spécifique • …
  7. Définition « Les organisations qui conçoivent des systèmes, 
 tendent

    inévitablement à produire des designs 
 qui sont des copies de la structure de communication de leur organisation. » 
 
 — Melvin Conway, 1968
  8. Pourquoi cette loi compte ? « Si l’architecture du système

    et l’architecture de l’organisation sont en désaccord, l’architecture de l’organisation gagne » 
 
 — Ruth Malan « Des différences significatives dans la modularité du produit sont cohérentes avec le fait que des équipes distribuées ont tendance à développer des produits plus modulaires » 
 
 — MIT - Harvard Business School “Exploring the Duality between Product and Organisational Architectures”
  9. On a toujours le choix • Contraindre le design technique

    
 -> assumer les conséquences humaines • Contraindre l’organisation humaine 
 -> assumer les conséquences techniques
  10. Organiser les équipes requiert une expertise technique Si nous avons

    des managers qui décident quels services vont être créés, par quelle équipe, nous avons implicitement des managers qui décident de l’infrastructure système 
 — Ruth Malan
  11. Définition « Les organisations qui conçoivent des systèmes, 
 tendent

    inévitablement à produire des designs 
 qui sont des copies de la structure de communication de leur organisation. » 
 
 — Melvin Conway, 1968
  12. Communication entre services • Qui communique avec qui • Type

    de communication (API, event bus, …) • Format • … ➡ définir, restreindre, contractualiser la communication
  13. • Interactions ? • Dépendances ? Entre les équipes •

    Comment ? • Pourquoi ? Communiquer avec une équipe
  14. Team API • Qui sommes nous ? • Que faisons

    nous ? • Que produisons nous ? • Comment travaillons nous ? • Comment nous contacter ? • Avec quelles équipes interagissons-nous ? • … https://github.com/TeamTopologies/Team-API-template
  15. Taille • Nombre de relations • 🎲 Dunbar’s numbers •

    40% du temps social avec 5 personnes • +20% avec +10 personnes
  16. Charge cognitive • Charge intrinsèque : le code, sa complexité,

    sa compréhension, … • Charge extrinsèque : son déploiement, sa configuration, … • Charge essentielle : interactions avec les autres services, …
  17. Ownership • L’équipe possède le logiciel (mais pas les individus)

    • Responsabilité de tout le monde = responsabilité de personne ➡ No shared ownership
  18. Équipe et non individus • Individus < dynamique de l’équipe

    Re:Work – the five keys to a successful Google team • État d’esprit équipe
  19. Un “framework”, 
 pour l’organisation des équipes, 
 dans le

    but d’obtenir le design technique souhaité
  20. Collaboration Sur une période donnée Pour découvrir de nouvelles choses

    Équipes travaillant de pair 2 équipes Souvent au moins un stream aligned
  21. Réductions de la charge cognitive • Meilleures pratiques, code :

    📉 charge intrinsèque ➡Enabling team • Meilleurs outils, processus : 📉 charge extrinsèque ➡Complicated subsystem, platform team • Meilleures docs, team API : 📉 charge essentielle ➡Expliciter X-as-a-service