Monolithe ou microservices : une question d'effectif

Demandez à une équipe pourquoi elle a découpé en microservices, elle répondra « pour la scalabilité ». Demandez-lui ensuite combien d'instances tourne chaque service : la réponse est souvent deux, la seconde pour la disponibilité. Le découpage n'a rien dimensionné. Il a, dans le meilleur des cas, permis à plusieurs équipes de livrer sans s'attendre. Dans le pire, il a imposé à une seule équipe le coût de coordination de plusieurs.

Je considère un service comme une unité d'autonomie d'équipe. Le nombre de services se déduit du nombre d'équipes qui se gênent, bien plus que de la charge, du volume de code ou de l'élégance du schéma. Les calculs qui suivent permettent de situer le seuil, avec des hypothèses posées que vous remplacerez par les vôtres.

La file de merge d'un monolithe qui grandit

Un monolithe a une seule file d'attente vers la production. Tant qu'elle est vide, il n'a que des avantages, et le calcul qui compte est celui de sa saturation.

Avec une CI de 15 minutes et une règle saine, où chaque merge est validé sur la branche main à jour, les merges sont sérialisés. Sur une journée de 8 heures, la file laisse passer 8 × 60 / 15 = 32 merges. Avec 12 développeurs qui mergent chacun une fois par jour, elle est occupée à 12 / 32 = 37 %. Avec 40 développeurs, la demande dépasse la capacité ; les PR attendent, se périment, repassent la CI, et le délai moyen explose bien avant les 100 %, comme dans toute file.

On peut repousser ce mur, et il faut le faire avant de découper : regrouper les merges par lots, ne lancer que les tests touchés par le changement, paralléliser la suite. Une CI ramenée à 6 minutes donne 80 merges par jour. Cela représente des semaines de travail d'outillage, contre des trimestres pour une extraction de service.