We are hiring!
● https://www.docker.com/career-openings/
● DevoxxFR booth
● Full remote
● Backend, frontend, infrastructure, data,
cloud database, …
● Junior to senior
Slide 4
Slide 4 text
● Délivrer de la valeur
● En continu
● Durablement
● Rapidement
Slide 5
Slide 5 text
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
Slide 6
Slide 6 text
Ce que vous ne trouverez pas ici
● Outil, framework, …
● Architecture
● Caractéristique, taille, …
● Docker, container, kubernetes, …
Slide 7
Slide 7 text
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
● …
Slide 8
Slide 8 text
Si les micro-services n’ont (généralement) rien à voir
avec la technique, avec quoi alors ?
Slide 9
Slide 9 text
Si les micro-services n’ont (généralement) rien à voir
avec la technique, avec quoi alors ?
Les humains
Slide 10
Slide 10 text
La loi de Conway
Slide 11
Slide 11 text
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
Slide 12
Slide 12 text
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”
Slide 13
Slide 13 text
On a toujours le choix
● Contraindre le design technique
-> assumer les conséquences humaines
● Contraindre l’organisation humaine
-> assumer les conséquences techniques
Slide 14
Slide 14 text
La manoeuvre inverse de Conway
Organiser les équipes pour atteindre le design
technique souhaité
Slide 15
Slide 15 text
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
Slide 16
Slide 16 text
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
Slide 17
Slide 17 text
Communication entre services
● Qui communique avec qui
● Type de communication (API, event bus, …)
● Format
● …
➡ définir, restreindre, contractualiser la
communication
Slide 18
Slide 18 text
Et pour les équipes ?
Slide 19
Slide 19 text
Définir, restreindre, contractualiser
la communication
Slide 20
Slide 20 text
La communication ?
Slide 21
Slide 21 text
No content
Slide 22
Slide 22 text
High bandwidth
Slide 23
Slide 23 text
High bandwidth
Slide 24
Slide 24 text
High bandwidth
Medium bandwidth
Slide 25
Slide 25 text
High bandwidth
Medium bandwidth
Slide 26
Slide 26 text
High bandwidth
Medium bandwidth
Low bandwidth
Slide 27
Slide 27 text
OK, en fait tu nous
réinventes les silos, non ?
Slide 28
Slide 28 text
OK, en fait tu nous
réinventes les silos, non ?
Non
Slide 29
Slide 29 text
● Interactions ?
● Dépendances ?
Entre les équipes
● Comment ?
● Pourquoi ?
Communiquer avec une équipe
Slide 30
Slide 30 text
Formaliser pour ne pas subir
Slide 31
Slide 31 text
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
Slide 32
Slide 32 text
C’est comment une équipe ?
Slide 33
Slide 33 text
Taille
● Nombre de relations
● 🎲 Dunbar’s numbers
● 40% du temps social avec 5
personnes
● +20% avec +10 personnes
Slide 34
Slide 34 text
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, …
Slide 35
Slide 35 text
Ownership
● L’équipe possède le logiciel (mais pas les individus)
● Responsabilité de tout le monde = responsabilité de personne
➡ No shared ownership
Slide 36
Slide 36 text
Diversité
➡ Plus de créativité
➡ Variété des points de vues et expériences
Slide 37
Slide 37 text
Équipe et non individus
● Individus < dynamique de l’équipe
Re:Work – the five keys to a successful Google team
● État d’esprit équipe
Slide 38
Slide 38 text
Responsabilités
● Limiter les responsabilités à la charge cognitive que l’équipe
puisse supporter
Slide 39
Slide 39 text
No content
Slide 40
Slide 40 text
Un “framework”,
pour l’organisation des équipes,
dans le but d’obtenir le design technique souhaité
Slide 41
Slide 41 text
4 topologies d’équipes, 3 modes de communication
Pour designer une organisation comme on
design un système
Slide 42
Slide 42 text
Les 4 topologies d’équipes
Slide 43
Slide 43 text
Stream-aligned team
Sur un segment métier
“you build it, you run it”
Principal
Slide 44
Slide 44 text
Enabling team
Aide, support aux stream aligned teams
Slide 45
Slide 45 text
Complicated subsystem team
Où une expertise spécifique est requise
Slide 46
Slide 46 text
Platform team
Fourni un produit interne
Accélère la livraison des autres équipes
Slide 47
Slide 47 text
Les 3 modes de communication
Slide 48
Slide 48 text
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
Slide 49
Slide 49 text
Facilitation
Aide
Mentoring
Ressources supplémentaires
1 équipe (généralement enabling)
facilite une autre
Slide 50
Slide 50 text
X-as-a-service
Consomme le produit d’une autre :
API, outil, produit
Toutes les équipes sauf enabling
Slide 51
Slide 51 text
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
Slide 52
Slide 52 text
A vous de jouer !
Définissez vos équipes
Explicitez les structures de communication
Slide 53
Slide 53 text
No content
Slide 54
Slide 54 text
Et dans la pratique ?
Slide 55
Slide 55 text
Communication is
hard
key
Slide 56
Slide 56 text
La technique aide
à réduire la charge cognitive
Slide 57
Slide 57 text
Il n’y a pas une bonne solution
mais plusieurs mauvaises
Slide 58
Slide 58 text
Merci
Slide 59
Slide 59 text
Questions, remarques, avis
@_crev_
Stand Docker
yves.brissaud@docker.com