En juillet 2016, un nom revient sans cesse dans les discussions d’architecture: Kubernetes. L’outil promet d’orchestrer des conteneurs à grande échelle, de gérer tout seul le déploiement, la mise à l’échelle pis la récupération après panne. La promesse est belle. Comme architecte, je la regarde avec intérêt — pis avec ma prudence habituelle, parce que je sens que ce qui simplifie d’un bord complique souvent de l’autre.

Le point de départ, c’est les conteneurs. On a appris à empaqueter chaque morceau d’application dans une boîte standard. Mais quand tu te retrouves avec des dizaines, des centaines de boîtes qui tournent, il faut quelqu’un — ou quelque chose — pour les placer, les surveiller, les redémarrer quand elles tombent. C’est ça, l’orchestration. C’est le travail que Kubernetes promet d’automatiser.

Ce que l’orchestrateur promet

L’idée séduisante, c’est de décrire l’état désiré — « je veux trois copies de ce service, toujours en santé » — pis de laisser le système s’arranger pour que ça reste vrai. Si une copie tombe, il en repart une. Si la charge monte, il en ajoute.

flowchart TD
    A[Je decris l'etat desire:<br/>3 copies en sante] --> B[Kubernetes surveille]
    B --> C{Une copie tombe?}
    C -->|Oui| D[Il en redemarre une]
    C -->|Non| E{Charge trop forte?}
    E -->|Oui| F[Il en ajoute]
    E -->|Non| B
    D --> B
    F --> B

Sur papier, c’est magnifique. L’auto-réparation, la mise à l’échelle automatique, le déploiement sans interruption: tout ce qu’on faisait à la main devient automatique. Pour une grosse application répartie, c’est exactement le genre de superpouvoir dont on rêve quand on gère beaucoup de pièces.

Le « complique aussi » que je ne tais pas

Mais voici le revers que je veux nommer franchement. Kubernetes ne fait pas disparaître la complexité — il la déplace. Tu n’as plus à placer tes conteneurs à la main, mais tu dois maintenant comprendre Kubernetes lui-même, qui est un système costaud avec ses propres concepts, sa propre courbe d’apprentissage, ses propres façons de planter.

C’est la question que je pose toujours. Kubernetes brille quand tu as vraiment beaucoup de services à orchestrer. Mais pour une équipe avec quelques applications, l’adopter, c’est peut-être s’acheter un bazooka pour tuer une mouche. La complexité de l’outil dépasserait alors le problème qu’il règle. Pour mes dealers, je veux la bonne taille d’outil, pas la plus à la mode.

Ce que je retiens

En juillet 2016, Kubernetes promet beaucoup — orchestration automatique, auto-réparation, mise à l’échelle — pis cette promesse est réelle pour qui a le bon problème. Mais il complique aussi: il ne supprime pas la complexité, il la déplace vers la maîtrise de l’orchestrateur lui-même.

Comme architecte, ma règle reste la même: faire correspondre la taille de l’outil à la taille du problème. Kubernetes est un superbe morceau d’ingénierie, mais ce n’est pas une réponse universelle. Je le garde dans ma boîte à outils, prêt pour le jour où l’échelle le justifiera vraiment. D’ici là, je me méfie de la tentation d’adopter une grosse machine juste parce que tout le monde en parle.