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 full-size 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 full-size slide

  3. ● Délivrer de la valeur


    ● En continu


    ● Durablement


    ● Rapidement

    View full-size 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 full-size slide

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


    ● Architecture


    ● Caractéristique, taille, …


    ● Docker, container, kubernetes, …

    View full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  9. La loi de Conway

    View full-size 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 full-size 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 full-size 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 full-size slide

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

    View full-size 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 full-size 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 full-size slide

  16. Communication entre services
    ● Qui communique avec qui


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


    ● Format


    ● …


    ➡ définir, restreindre, contractualiser la
    communication

    View full-size slide

  17. Et pour les équipes ?

    View full-size slide

  18. Définir, restreindre, contractualiser
    la communication

    View full-size slide

  19. La communication ?

    View full-size slide

  20. High bandwidth

    View full-size slide

  21. High bandwidth

    View full-size slide

  22. High bandwidth
    Medium bandwidth

    View full-size slide

  23. High bandwidth
    Medium bandwidth

    View full-size slide

  24. High bandwidth
    Medium bandwidth
    Low bandwidth

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  27. ● Interactions ?


    ● Dépendances ?


    Entre les équipes
    ● Comment ?


    ● Pourquoi ?


    Communiquer avec une équipe

    View full-size slide

  28. Formaliser pour ne pas subir

    View full-size slide

  29. 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 full-size slide

  30. C’est comment une équipe ?

    View full-size slide

  31. Taille
    ● Nombre de relations


    ● 🎲 Dunbar’s numbers


    ● 40% du temps social avec 5
    personnes


    ● +20% avec +10 personnes

    View full-size slide

  32. 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 full-size slide

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


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


    ➡ No shared ownership

    View full-size slide

  34. Diversité
    ➡ Plus de créativité


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

    View full-size slide

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


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


    ● État d’esprit équipe

    View full-size slide

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

    View full-size slide

  37. Un “framework”,

    pour l’organisation des équipes,

    dans le but d’obtenir le design technique souhaité

    View full-size slide

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

    View full-size slide

  39. Les 4 topologies d’équipes

    View full-size slide

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


    “you build it, you run it”


    Principal

    View full-size slide

  41. Enabling team
    Aide, support aux stream aligned teams

    View full-size slide

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

    View full-size slide

  43. Platform team
    Fourni un produit interne


    Accélère la livraison des autres équipes

    View full-size slide

  44. Les 3 modes de communication

    View full-size slide

  45. 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 full-size slide

  46. Facilitation
    Aide


    Mentoring


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

    facilite une autre

    View full-size slide

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


    API, outil, produit
    Toutes les équipes sauf enabling

    View full-size slide

  48. 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 full-size slide

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


    Explicitez les structures de communication

    View full-size slide

  50. Et dans la pratique ?

    View full-size slide

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

    View full-size slide

  52. 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 full-size slide

  53. Communication is
    hard


    key

    View full-size slide

  54. La technique aide


    à réduire la charge cognitive

    View full-size slide

  55. Il n’y a pas une bonne solution


    mais plusieurs mauvaises

    View full-size slide

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

    View full-size slide

  57. 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 full-size slide