Pourquoi Semji a quitté Docker Swarm pour Kubernetes ?

Le retour d’expérience complet du CTO 3 ans après la migration (roadmap, architecture, résultats).

Argh… la magie n’a pas opérée 🪄 Réessayez avec une adresse e-mail professionnelle.

🚀 Houston, inscription confirmée ! Le cas client vient de quitter la rampe de lancement.

Recevoir le REX

dans ma boîte mail 👇

Votre prénom

Votre nom

Votre entreprise

Votre poste

Votre e-mail

Veuillez renseigner une adresse e-mail professionnelle pour poursuivre 🙏

En soumettant ce formulaire, je jure que mes intentions sont mauvaises. Blague à part, en soumettant le formulaire, vous acceptez de recevoir les communications de DoNow. Si vous aimez les longs parchemins, vous pouvez consulter à notre politique de confidentialité.

Pionner de l’IA & référence du SEO : Semji s’est taillé une place de choix sur le marché du logiciel ces dernières années.

Mais qui dit croissance, dit montée en charge, pics de trafic et risques d’incidents. Semji s’est retrouvé face aux limites de Docker Swarm, son socle historique.

PEn 2023, il est temps de lui faires ses adieux. Comme de grands noms du logiciel avant lui, Semji entame une migration vers Kubernetes, le standard du marché pour l’orchestration et la scalabilité.

Trois ans plus tard, Olivier Balais, CTO de l’entreprise revient sur son expérience : ce qui a déclenché la décision, les points clés de la roadmap, l’architecture cible et les résultats du cluster, aujourd’hui en production.

Ce que vous allez trouver dans ce REX :

Le contexte métier d’un SaaS data-heavy en pleine croissance

La roadmap + le schéma d’architecture post-migration

Les décisions CTO + best practices DevOps

Les résultats de la migration : élasticité, coûts, DevEx, SOC2

Docker Swarm : ce qui a freiné Semji en pleine croissance

Cluster non maintenu : version vieillissante, risques de sécurité, instabilités et crashs difficiles à expliquer.

Gestion manuelle du scaling : avec la hausse du trafic, chaque redimensionnement devait être géré à la main.

Coûts d’infrastructure difficiles à estimer : manque de visibilité et de précision sur les dépenses.

Socle peu adapté aux exigences de conformité : peu de traçabilité et de standardisation dans la gestion du cluster.

« On a fait x2 en ARR en 18 mois après le lancement du projet. Avec notre ancienne infrastructure, on aurait eu du mal à suivre cette croissance. »

Olivier Balais, CTO de Semji.

Kubernetes, IaC, GitOps : les standards d’infrastructure des plateformes en croissance

Doctolib, Pennylane, Swile… Avant Semji, de grands noms du logiciel sont passés par là. Depuis plus de dix ans, Kubernetes s’est imposé comme le standard de l’orchestration.

Approche Infrastructure as Code, GitOps, écosystème riche d’add-ons pour gérer l’autoscaling, l’observabilité, la CI/CD ou encore l’optimisation des coûts : Kubernetes impose un cadre clair à l’infrastructure.

Un passage presque obligé en phase de scale, notamment pour des enjeux de gouvernance. Pour Semji, la migration a d’ailleurs largement facilité l’obtention de la certification SOC 2 nécessaire à son ambition internationale.

ROI Kubernetes : attention à l’over-engineering

C’est bien connu, Kubernetes est une machine puissante et ses possibilités sont vastes. Le risque de construire un système trop complexe est réel. C’est ce qui peut refroidir les entreprises en phase de scale.

Pour que la migration crée de la valeur, elle doit être cadrée et construite avec les équipes. L’objectif n’est pas d’empiler des briques, mais de choisir les bons outils et de les configurer selon les besoins réels de la plateforme.

Dans ce REX, vous trouverez la méthode utilisée par Semji : l’audit, la roadmap de migration en 12 semaines, les conseils du CTO et l’architecture cible retenue.

« L’idée était de montrer que Kubernetes n’est pas surdimensionné par rapport à leurs besoins. Que ce n’est pas une Ferrari juste pour aller à la boulangerie. »

Hugo Martin, ingénieur DevOps chez DoNow.