Microservices, parce que, la taille, ça compte !

Ippon© — Microservices, parce que la taille, ça compte !
Microservi
ces
Parce que, la taille, ça
compte !

Ippon© — Microservices, parce que la taille, ça compte ! 2
Jean-RémyRevy
#Architecture #API #DDD
#DevOps #Agility
#Lean Manager #Quality
@JeanRemyRevy
https://www.linkedin.com/in/jeanremyrevy/
https://stackoverflow.com/users/1047365/jean-rémy-revy

SOMMAIRE
PARTIE01
3
De quoi parle-
t-on ?
PARTIE02
Intuitions et
réflexions.
PARTIE03
Ok, comment
on fait alors !

Microservices
4
01
De quoi parle-t-on
exactement

Ippon© — Microservices, parce que la taille, ça compte ! 5

Microservices
6
02
Ok, mais alors c’est
quoi la bonne taille ?

Quelletaille?Simple,basique!
1 microservice = 1 base / un schéma ?
7
Limiter la taille d’un
microservice à une base (ou
un schéma) est une
évidence.
C’est même une bonne
pratique d’architecture en soi,
quelle qu’en soit son
implémentation.

8
Un seul microservice accède
à sa base et expose une
seule API.
1 table = 1 entity (Java/.Net)
1 microservice = 1 API
1 ressources ~= entity
⇒
1 API ~= entity * (1..7) endpoints

9
On atteint vite les limites du
modèle si la base elle-même
contient des dizaines, voire
des centaines de tables.
?

Quelletaille?Nanoservice?
1 microservice = 1 table / 1 collection ?
10
Rendons le modèle
précédent plus exigeant, en
limitant l’accès d’un micro
service à UNE SEULE
collection.
Nous sommes ainsi certain
d’avoir une complexité
cognitive limitée par
conception.

11
Un seul microservice accède
à sa base qui ne contient
qu’une seule collection et
expose une seule API.
1 table = 1 entity (.Net)
1 microservice = 1 API
1 API ~= 1 à 7 endpoints

12
Hélas nous perdons en
consistance, le module est
alors rarement autonome.
Par conséquent, il est
nécessaire d’enchaîner les
appels à d’autres services, ce
qui entraîne des échanges bien
trop verbeux ou trop long,
même avec des protocoles
comme gRPC + protobuff.

Quelletaille?Laloideconway
1 microservice = 1 équipe ?
13
Any organization that
designs a system (defined
broadly) will produce a
design whose structure is a
copy of the organization's
communication structure.
Alors prenons acte et alignons
fonctionnel et organisationnel !

14
Dans une stratégie “produit”,
une équipe est propriétaire
de son périmètre.
Par transitivité des principes
agiles, on est en mesure de
borner la taille d’une feature
team, et donc :
1 µsvc => 1 équipe (3 à 8 dév)

15
Mais est-ce qu’une équipe ne
doit gérer qu’un seul
microservice ? Probablement
pas.
Comment gérer les produits en
fin de vie (en mode MCO) ?
Et ça dépends donc beaucoup
de l’équipe de développement.

Quelletaille?DDDàlarescousse
1 microservice = 1 bounded context ?
16
Dans son approche de
modélisation, Eric Evans (cité
par Martin Fowler) définit la
notion de “Contexte Borné”.
Si Eric Evans en a l’intuition en
2003, le marché “sait” que c’est
une voie intéressante depuis
2012, et le marché Français
depuis 2015 (nombreuses
conférences).

17
Vocabulaire partagé, entités,
modélisation et usage /
besoin forment cette limite
Ces contextes représentent la
limite à l’intérieur de laquelle
une certaine modélisation
représente le domaine.

18
Ok … mais ? C’est quoi la
bonne taille d’un bounded
context ?
Certes, Domain Driven Design
avec une grande quantité de
pattern stratégique et
tactiques qui guident vers une
meilleurs maintenabilité, mais
sans donner de “taille”.

Microservices-Quelletaille?Laloidemiller
1 microservice = 4 ± 2 agrégats racine ? (le nb magique)
19
Georges A. Miller a publié en
1956 un article de psychologie
: la mémoire à court terme de
l’humain moyen ne peut
mémoriser que 7 éléments,
+/- 2 !
Des études plus récentes (2011)
suggèrent que ce nombre
s’établit, en fonction de
l’expérience du sujet, entre 3
et 4, et plus facilement par bloc.

Microservices-Quelletaille?Lenombremagique
1 microservice = 5 ± 2 tables / agrégats ?
20
Pour une architecture
maintenable, faisons donc
en sorte que cette “logique
métier” rentre dans notre
tête.
Gardons les principes
précédents, et limitons donc le
nombre de concepts
principaux à 3 ou 4, un peu
plus si l’équipe maîtrise son
sujet.
Ag.
Root Ag.
Root
Ag.
Root
Value
Object
Entity
Entity
Table A
Table B
Table fille
table C
Table fille
Table fille

Microservices-Quelletaille?Lenombremagique
1 microservice = 4 ± 2 tables / agrégats ?
21
Sur le papier, c’est plutôt une
bonne limite (et si vous
deviez en garder une, prenez
celle-là)
Dans les faits, je ne trouve pas
de corrélation évidente entre
l’augmentation du nombre
d'agrégats et une perte
“évidente” de maintenabilité
avant 10 agrégats

Microservices-C’estpasqu’unequestiondetaille!
22
Cequicompte,c’estlamanièredontons’ensert!!!!

Lesclés:çasechangevite!
1 microservice = 1 releases (2,5 à 3 mois)?
23
Maintenabilité et facilité à
changer sont en fait des
moyens derrière le KPI Roi :
le Time to Market !
Si l’ensemble des éléments
précédents ont du sens, même
pris indépendamment, il
s’avère que la taille idéale c’est
lorsque l’équipe de
développement est en mesure
de changer son microservice
en une release !

Lesclés:çaseconçoitenlimitantlacomplexité
1 microservice = 1 bounded context
24
Vous n’auriez pas entendu
parler d’une démarche de
conception qui vise à tacler
la complexité au coeur du
logiciel ? Domain Driven
Design !
L’ensemble des patterns
stratégiques et tactiques
guident vers une meilleur
maintenabilité.

Lesclés:çadépenddel’expériencedel’équipe
Plus c’est petit, plus il faut d’expérience
25
Réciproquement à la théorie
de Miller, en faire moins
(+petit) demande de
l’expérience.
Si votre équipe n’est pas
mature sur le sujet, ou qu’elle
n’a que peu d’expérience,
commencer par découper
“gros” avant de viser petit.

Microservices
27
03
Mais alors,
comment on fait ?

Microservices-Mais alors, comment on fait ?
28
Onprendletempsdeconcevoir,etdemanièreitérative!
https://github.com/ddd-crew/
ddd-starter-modelling-process

Rendre une architecture
maintenable demande un certain
investissement en conception.
—
L’utilisation de différents ateliers
(Event Storming Big picture
notamment) permet de mieux définir
ces contextes, et la mise en oeuvre
des patterns tactiques de Domain
Driven Design assure une meilleure
mise en œuvre.
29
VoilàcommentonfaitchezIppon
Product Discovery
Cadrage produit au plus près des
besoins :
Business Lean Canvas
User Journey Mapping
…
Event storming
Cadrage technico-fonctionnel
commun pour définir ensemble
les bonnes limites (Pattern DDD
Stratégiques)
Planning
User Story Mapping +
Xtrem Quotation +
Example Mapping +
...
Delivery
Clean Architecture (Patterns
Tactique DDD.)
Clean Code
Testing
Un processus de design “plus complet”

30
Formation et accompagnement
sont deux des trois piliers de la
conduite du changement
—
Au-delà des ateliers, des formations
et un accompagnement idoine
représentent le meilleur moyen de
progresser.
Onseforme,onlitetonpratique!Bref,oncraft!

31
Formation et accompagnement
sont deux des trois piliers de la
conduite du changement
—
Au delà des ateliers, des formations
et un accompagnement idoine
représentent le meilleur moyen de
progresser.
Onseforme,onlitetonpratique!Bref,oncraft!

www.ippon.fr
contact@ippon.fr +33 1 46 12 48 48 @ipponTech

Microservices, parce que, la taille, ça compte !

Recommended

Recommended

More Related Content

Similar to Microservices, parce que, la taille, ça compte !

Similar to Microservices, parce que, la taille, ça compte ! (20)

Microservices, parce que, la taille, ça compte !