En juillet 2015, il y a un mot qui fait rêver tous les architectes: microservices. L’idée de découper une grosse application monolithique en plein de petits services indépendants, chacun responsable d’une seule chose. Comme architecte chez un joueur du vélo, je trouve la promesse séduisante. Mais j’ai assez d’expérience pour savoir qu’une belle promesse cache souvent une facture qu’on voit pas tout de suite. Pis avec les microservices, la facture, c’est la multiplication des pièces.

La promesse est claire: au lieu d’un gros bloc difficile à changer, on a des petits morceaux qu’on peut développer, déployer pis faire évoluer séparément. Une équipe touche un service sans casser les autres. Sur papier, c’est le rêve de la souplesse.

La promesse séduisante

Le monolithe, ce gros bloc unique, devient lourd à mesure qu’il grossit. Le découper en services indépendants, ça donne l’impression de retrouver de l’agilité.

flowchart TD
    Q{Comment découper<br/>l'application?} -->|Un seul bloc| M[Monolithe]
    Q -->|Plein de petits services| S[Microservices]
    M --> M1[Difficile à changer]
    M1 --> M2[Une modif risque<br/>de tout casser]
    S --> S1[Service commandes]
    S --> S2[Service clients]
    S --> S3[Service paiement]
    S1 --> R[Souplesse... en théorie]
    S2 --> R
    S3 --> R
    R -.mais.-> C[Le câblage entre services<br/>devient le nouveau casse-tête]

Jusque-là, tout va bien. Mais voici ce que la brochure oublie de mentionner: en découpant l’application en vingt morceaux, on n’a pas fait disparaître la complexité. On l’a déplacée. Elle était dans le code; elle est maintenant entre les services. Pis cette complexité-là, entre les pièces, est souvent plus sournoise.

Le revers: la multiplication des pièces

Là où un monolithe avait un seul endroit à déployer, à surveiller, à déboguer, on se retrouve maintenant avec vingt services qui doivent se parler à travers le réseau. Pis chaque conversation entre services, c’est une nouvelle occasion que ça brise.

C’est ça, le piège que je veux nommer. Les microservices, c’est puissant, mais c’est pas gratuit. On échange la complexité d’un gros bloc contre la complexité d’un réseau de petits blocs. Pour une grosse organisation avec plein d’équipes, l’échange peut valoir la peine. Pour une équipe moyenne qui se lance là-dedans par effet de mode, c’est souvent un cauchemar opérationnel.

Mon réflexe d’architecte

Devant la mode des microservices, ma question est toujours la même: est-ce qu’on a vraiment le problème que ça règle? Les microservices brillent quand on a beaucoup d’équipes qui se nuisent dans un même monolithe. Si on n’a pas ce problème-là, on s’achète de la complexité distribuée sans le bénéfice.

Pour mes dealers, je préfère commencer simple, un système qu’on comprend pis qu’on déploie d’un coup, pis découper seulement quand une vraie douleur le justifie. Découper trop tôt, c’est multiplier les pièces avant même de savoir lesquelles méritent d’être séparées.

Ce que je retiens

En juillet 2015, les microservices promettent la souplesse, puis multiplient les pièces. La complexité ne disparaît pas quand on découpe un monolithe: elle déménage dans l’espace entre les services, où elle devient plus dure à voir pis à déboguer.

Mon conseil d’architecte, c’est la prudence. Les microservices sont un outil puissant pour les bons problèmes — beaucoup d’équipes, beaucoup d’échelle. Mais adoptés par effet de mode, ils transforment une application qu’on comprenait en un réseau qu’on subit. Commencer simple, découper seulement quand la douleur le justifie: voilà la règle que je garde pour pas me noyer dans mes propres pièces.