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

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

AlpesCraft 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 ce qu'on essaye 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

June 09, 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 ?
    AlpesCraft 2022


    Yves Brissaud


    @_crev_

    View Slide

  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

    View Slide

  3. ● Délivrer de la valeur


    ● En continu


    ● Durablement


    ● Rapidement

    View Slide

  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

    View Slide

  5. Ce que vous ne trouverez pas ici
    ● Outil, framework, …


    ● Architecture


    ● Caractéristique, taille, …


    ● Docker, container, kubernetes, …

    View Slide

  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


    ● …

    View Slide

  7. Si les micro-services n’ont (généralement) rien à voir
    avec la technique, avec quoi alors ?

    View Slide

  8. Si les micro-services n’ont (généralement) rien à voir
    avec la technique, avec quoi alors ?
    Les humains

    View Slide

  9. La loi de Conway

    View Slide

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

    View Slide

  11. 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”

    View Slide

  12. On a toujours le choix
    ● Contraindre le design technique

    -> assumer les conséquences humaines
    ● Contraindre l’organisation humaine

    -> assumer les conséquences techniques

    View Slide

  13. La manoeuvre inverse de Conway
    Organiser les équipes pour atteindre le design
    technique souhaité

    View Slide

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

    View Slide

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

    View Slide

  16. Communication entre services
    ● Qui communique avec qui


    ● Type de communication (API, event bus, …)


    ● Format


    ● …


    ➡ définir, restreindre, contractualiser la
    communication

    View Slide

  17. Et pour les équipes ?

    View Slide

  18. Définir, restreindre, contractualiser
    la communication

    View Slide

  19. La communication ?

    View Slide

  20. View Slide

  21. High bandwidth

    View Slide

  22. High bandwidth

    View Slide

  23. High bandwidth
    Medium bandwidth

    View Slide

  24. High bandwidth
    Medium bandwidth

    View Slide

  25. High bandwidth
    Medium bandwidth
    Low bandwidth

    View Slide

  26. OK, en fait tu nous
    réinventes les silos, non ?

    View Slide

  27. OK, en fait tu nous
    réinventes les silos, non ?
    Non

    View Slide

  28. ● Interactions ?


    ● Dépendances ?


    Entre les équipes
    ● Comment ?


    ● Pourquoi ?


    Communiquer avec une équipe

    View Slide

  29. Formaliser pour ne pas subir

    View Slide

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

    View Slide

  31. C’est comment une équipe ?

    View Slide

  32. Taille
    ● Nombre de relations


    ● 🎲 Dunbar’s numbers


    ● 40% du temps social avec 5
    personnes


    ● +20% avec +10 personnes

    View Slide

  33. 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, …

    View Slide

  34. Ownership
    ● L’équipe possède le logiciel (mais pas les individus)


    ● Responsabilité de tout le monde = responsabilité de personne


    ➡ No shared ownership

    View Slide

  35. Diversité
    ➡ Plus de créativité


    ➡ Variété des points de vues et expériences

    View Slide

  36. Équipe et non individus
    ● Individus < dynamique de l’équipe


    Re:Work – the five keys to a successful Google team


    ● État d’esprit équipe

    View Slide

  37. Responsabilités
    ● Limiter les responsabilités à la charge cognitive que l’équipe
    puisse supporter

    View Slide

  38. View Slide

  39. Un “framework”,

    pour l’organisation des équipes,

    dans le but d’obtenir le design technique souhaité

    View Slide

  40. 4 topologies d’équipes, 3 modes de communication
    Pour designer une organisation comme on
    design un système

    View Slide

  41. Les 4 topologies d’équipes

    View Slide

  42. Stream-aligned team
    Sur un segment métier


    “you build it, you run it”


    Principal

    View Slide

  43. Enabling team
    Aide, support aux stream aligned teams

    View Slide

  44. Complicated subsystem team
    Où une expertise spécifique est requise

    View Slide

  45. Platform team
    Fourni un produit interne


    Accélère la livraison des autres équipes

    View Slide

  46. Les 3 modes de communication

    View Slide

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

    View Slide

  48. Facilitation
    Aide


    Mentoring


    Ressources supplémentaires
    1 équipe (généralement enabling)

    facilite une autre

    View Slide

  49. X-as-a-service
    Consomme le produit d’une autre :


    API, outil, produit
    Toutes les équipes sauf enabling

    View Slide

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

    View Slide

  51. A vous de jouer !
    Définissez vos équipes


    Explicitez les structures de communication

    View Slide

  52. View Slide

  53. Et dans la pratique ?

    View Slide

  54. Fin 2019 - 2021
    23+
    ~7
    Mi 2022
    Équipes

    View Slide

  55. View Slide

  56. Dockercon: Team Topologies Methodologies While Renavigating and Rescaling
    the Industry Standard for Containerization
    🎥 https://docker.events.cube365.net/dockercon/2022/content/Videos/
    1adc6649-99cd-4535-880a-1bc02b7483f1


    💬 https://teamtopologies.com/industry-examples/rebuilding-and-
    scaling-product-development-at-docker-using-team-topologies

    View Slide

  57. Communication is
    hard


    key

    View Slide

  58. La technique aide


    à réduire la charge cognitive

    View Slide

  59. Il n’y a pas une bonne solution


    mais plusieurs mauvaises

    View Slide

  60. Merci

    View Slide

  61. Questions, remarques, avis
    @_crev_ [email protected]
    https://roti.express/r/alp-02

    View Slide

  62. Illustrations, ressources
    https://teamtopologies.com/


    https://github.com/TeamTopologies
    https://unsplash.com/photos/r3pIy-3Xgmg


    https://unsplash.com/photos/634KBk3AXNA


    https://unsplash.com/photos/7kSnMLGoR9w


    https://unsplash.com/photos/cWcuKut1RAE


    https://unsplash.com/photos/LJhXYHxPfEY


    https://telegram.org/blog/stickers-meet-art-and-history

    View Slide