Kubernetes : besoin réel… ou complexité auto-infligée ?

Je le dis souvent : j’adore l’écosystème Kubernetes.

À grande échelle, c’est un bijou technologique :
✅ orchestrer des centaines de microservices
✅ mutualiser une plateforme entre plusieurs équipes
✅ tirer le maximum de l’infra avec auto-scaling, résilience, observabilité

Mais trop souvent, je vois Kubernetes utilisé comme un réflexe, et non comme une décision réfléchie 👇

❌ Pour un MVP qui n’a pas encore trouvé son marché (👀 post sur les microservices)
❌ Pour une petite application interne avec une API et une base de données
❌ Par une équipe qui n’a pas (encore) la maturité DevOps pour gérer la complexité

Résultat :

Des coûts d’infrastructure qui explosent
Des déploiements plus lourds que les fonctionnalités qu’ils hébergent
Des équipes paralysées par des problèmes d’orchestration au lieu de se concentrer sur la valeur métier

Chez PeriScop, j’ai pris un chemin différent :

➡️ Docker Compose, simple et efficace.

Pourquoi ?

• Parce qu’au démarrage, chaque euro investi doit aller à la valeur produite, pas à l’infra inutile.
• Parce que la simplicité paie : moins de pièces mobiles, moins de risques, plus de focus sur le cœur du besoin.
• Parce qu’aujourd’hui, nous ne savons pas encore dans le détail quels outils et quelle infra seront vraiment nécessaires. Garder cette souplesse nous permet d’ajuster sans surinvestir trop tôt.
• Parce qu’un monolithe modulaire ou une stack containerisée de façon simple n’empêche pas d’évoluer : si un jour la charge, l’équipe ou la complexité justifient Kubernetes, la transition se fait naturellement.

Bref, commencer simple, scaler ensuite.

🧭 Kubernetes est une techno incroyable. Mais comme toute arme puissante, il faut savoir quand dégainer et quand garder le couteau suisse.