Le parcours Kubernetes de Navixy : échelle mondiale, modularité et DevOps convivial pour les développeurs.

Kubernetes n'est plus seulement un mot à la mode dans la Silicon Valley - il alimente des systèmes critiques dans tous les secteurs d'activité. En fait, près de 43 % des entreprises utilisent Kubernetes pour des déploiements IoT (et 31 % prévoient de l'adopter). De la plateforme de streaming de 3 millions d'appareils de Bose aux fournisseurs de maisons intelligentes gérant des millions de messages avec une latence inférieure à 200 ms, Kubernetes a prouvé qu'il pouvait offrir une échelle et une fiabilité sérieuses dans les domaines de l'IoT et de la télématique.
Au cours de l'année écoulée, Navixy a décidé qu'il était temps de rejoindre ces rangs. Nous avons entrepris une transformation majeure : faire passer notre cloud télématique de serveurs statiques à une architecture conteneurisée alimentée par Kubernetes. Il s'agissait d'une évolution logique pour garantir une évolutivité et une stabilité illimitées au fur et à mesure de notre croissance. Aujourd'hui, nous aimerions partager ce qui a changé, pourquoi nous l'avons fait et comment cela profite à nos partenaires, développeurs et à notre équipe.
Pourquoi Kubernetes, et pourquoi maintenant ? Pour faire simple, nous nous préparons pour l'avenir. La plateforme Navixy gère le suivi GPS en temps réel, les données des capteurs IoT et les applications de gestion de flotte - des centaines de milliers d'appareils diffusant des données en parallèle. Nous devons traiter ces données à la volée, 24 heures sur 24, 7 jours sur 7, dans le monde entier. Kubernetes nous offre la flexibilité nécessaire pour répondre à ces besoins en orchestrant nos dizaines de microservices à la demande. Notre système peut désormais s'adapter dynamiquement à des charges changeantes, qu'il s'agisse d'un afflux de nouveaux appareils en ligne ou de rafales périodiques de données provenant du terrain. Dans le domaine de l'informatique, rien n'est figé ; cette mesure nous permet de ne pas atteindre les limites de l'infrastructure au fur et à mesure que notre clientèle s'élargit.
En bref, voici ce que Kubernetes apporte à Navixy :
- Mise à l'échelle efficace en temps réelNouspouvons gérer des charges de données croissantes et des milliers de connexions d'appareils simultanées sans transpirer, en ajustant les ressources en temps réel pour répondre à la demande.
- Fiabilité accrueLesfonctions d'autoréparation et de redondance deKubernetesréduisent considérablement les temps d'arrêt. Si un service tombe en panne, Kubernetes le redémarre automatiquement ou transfère la charge, ce qui se traduit par une réduction des pannes et une expérience plus fluide pour les utilisateurs.
- Livraison plus rapide des fonctionnalitésLesdéploiementsautomatisésde conteneurs accélèrent nos cycles de publication. Nous pouvons déployer des mises à jour (ou revenir en arrière si nécessaire) beaucoup plus rapidement qu'auparavant, de sorte que les partenaires et les clients bénéficient d'améliorations continues sans interruption.
- Garanties de mise à l'échelle rentableEnne mettant à l'échelle automatiquement que ce qui est nécessaire et en empaquetant efficacement les charges de travail, nous évitons le surprovisionnement. Les garde-fous en place empêchent de "s'étendre pour s'étendre", ce qui permet à l'infrastructure de rester légère et rentable.
Qu'est-ce qui a changé dans notre plateforme ?
Cinq ans se sont écoulés depuis notre dernier examen approfondi de l'infrastructure de Navixy, et beaucoup de choses ont changé. Le plus grand changement, bien sûr, est la migration vers Kubernetes. Nous avons décomposé notre plateforme autrefois monolithique en microservices et nous les exécutons dans des conteneurs, orchestrés par Kubernetes sur un cloud distribué. Concrètement, Kubernetes gère désormais tout, des services d'ingestion de données aux API et aux modules de logique d'entreprise - toutes les pièces mobiles sous le capot. Cette approche "cloud-native" a immédiatement porté ses fruits en termes de performances et de résilience : Kubernetes détecte les défaillances et y remédie automatiquement, de sorte qu'un problème au niveau d'un composant n'entraîne plus de panne. Les déploiements qui étaient risqués et lents sont désormais routiniers, les mises à jour sont plus fluides et les retours en arrière sont aussi simples que le redémarrage d'un conteneur. En bref, la plateforme Navixy est devenue plus modulaire, plus agile et plus robuste.
Même si nos clients et partenaires ne voient pas directement Kubernetes, ils ressentent la différence dans le service quotidien. Voici comment :
- Une plus grande fiabilité. La plateforme est plus stable que jamais. Kubernetes nous aide à détecter les défaillances et à récupérer automatiquement, ce qui réduit les interruptions. Nous promettons confortablement un temps de disponibilité de 99,99 % et avons même atteint une disponibilité de "cinq neuf" dans certains quartiers - ce qui signifie pratiquement aucun temps d'arrêt.
- Une innovation plus rapide. Grâce à l'automatisation du déploiement, nous pouvons livrer des mises à jour plus fréquemment. Les clients et les intégrateurs ont accès aux nouvelles fonctionnalités et aux améliorations plus rapidement, sans avoir à attendre des versions importantes peu fréquentes. Notre pipeline CI/CD veille à ce que les mises à jour soient diffusées en douceur et en toute sécurité, par tranches incrémentielles.
- Évolution sans effort. Au fur et à mesure que nos clients grandissent (plus d'appareils, plus de données, plus d'utilisateurs), le nuage Navixy évolue automatiquement avec eux. Nous pouvons ajouter de la capacité à la volée et même étendre la plateforme à de nouvelles régions rapidement. Il n'y a pas de pénalité de performance pour la croissance - qu'un client ait 10 appareils ou 10 000, l'expérience reste rapide.
Pour un SaaS télématique destiné à un public mondial, ces améliorations changent la donne. Une application de gestion de flotte en Amérique du Nord et un réseau de capteurs IoT en Europe bénéficient tous deux d'une faible latence et d'un service fiable parce qu'en coulisses, notre infrastructure peut s 'étendre, se contracter et s'auto-régénérer en fonction des besoins. Et surtout, tous ces changements se font sans accroître la complexité pour nos utilisateurs - tout se passe sous le capot, en améliorant discrètement les choses.
Reconstruire notre infrastructure (sans perdre de temps)
Alors, comment avons-nous réussi à faire cela ? Voici un aperçu des coulisses de notre migration vers Kubernetes. Spoiler : cela a nécessité beaucoup de planification, quelques nuits blanches et une équipe DevOps qui ne croit pas aux économies de bouts de chandelle.
Il y a environ trois ans, nous avons décidé qu'il était temps de repenser la façon dont notre infrastructure était configurée. Tout fonctionnait bien, mais nous avions des objectifs plus ambitieux : nous voulions être plus flexibles, réagir plus rapidement aux changements et éliminer les goulets d'étranglement qui pouvaient nous freiner. Kubernetes figurait déjà sur notre feuille de route (il était resté dans notre carnet de commandes et réclamait de l'attention), et c'était le moment idéal pour passer à l'action. Après tout, quoi de plus gratifiant pour une équipe DevOps que de passer à l'Infrastructure-as-Code et de moderniser la pile, n'est-ce pas ? 😁
Étape 1 : GitOps et CI/CD - Préparer le terrain
Nous savions que le passage à Kubernetes ne réussirait que si nos processus faisaient également peau neuve. Nous avons donc commencé par revoir la manière dont nous livrons les logiciels. Désormais, l'ensemble de la configuration de notre plateforme - du code de service aux manifestes Kubernetes - se trouve dans un référentiel Git, qui sert de source unique de vérité. Chaque fois qu'un développeur ou un ingénieur DevOps apporte un changement, des pipelines CI/CD automatisés se mettent en place pour construire, tester et déployer ce changement dans nos environnements. En pratique, chaque service Navixy est construit non seulement comme un binaire, mais aussi comme une image de conteneur. Cela signifie que ce qui fonctionne sur la machine d'un développeur est exactement ce qui fonctionne en production (plus de problèmes de "fonctionne sur ma machine"). Nous avons pleinement adopté les modèles de déploiement GitOps : grâce à des outils comme Argo CD, nos clusters se réconcilient en permanence avec l'état déclaré dans Git. Si cela vous semble fantaisiste, pensez-y de la manière suivante : tout changement, qu'il s'agisse de code ou de configuration, est appliqué par le biais de commits contrôlés par version, et Kubernetes fait en sorte qu'il en soit ainsi. Cela nous permet de bénéficier d'une transparence et d'un contrôle considérables. Nous pouvons savoir quelle version d'un service est en cours d'exécution et où, et si quelque chose ne va pas, il est aussi facile de revenir en arrière que d'annuler un commit Git. Notre pipeline est véritablement devenu une plateforme de développement interne pour les ingénieurs de Navixy, automatisant tout, des builds aux mises à jour de l'infrastructure. Il est moderne, modulaire et transparent, ce qui permet à notre équipe de se concentrer sur les fonctionnalités au lieu de s'occuper des serveurs.
Figure : Le pipeline GitOps CI/CD de Navixy simplifie la livraison - le code et la configuration dans Git déclenchent des builds automatisés (CI), la conteneurisation et les déploiements vers des clusters Kubernetes (CD). Les outils de surveillance (Prometheus, Grafana, Graylog) ferment ensuite la boucle de rétroaction, fournissant une observabilité de la santé de la plateforme pour une amélioration continue.
L'une des grandes réussites de cette nouvelle approche a été la possibilité de publier une édition conteneurisée de Navixy sur site parallèlement à notre SaaS dans le nuage. En fait, c'était l'un des premiers grands résultats de l'"étape 1". En conteneurisant l'ensemble de notre pile, nous avons facilité le conditionnement de Navixy pour les clients qui souhaitent l'exécuter dans leur propre environnement. Il existe maintenant un script d'installation facile (littéralement appelé Easy installation) qui déploie Navixy sur les serveurs d'un client via Docker/Kubernetes - aucune expertise Linux approfondie n'est nécessaire. C'est une grosse affaire pour les partenaires de distribution qui servent des clients gouvernementaux ou d'entreprise avec des besoins stricts en matière de résidence des données. Peu de fournisseurs de solutions télématiques SaaS offrent ce type de flexibilité, mais l'investissement de Navixy dans DevOps a permis de maintenir une base de code unique qui peut fonctionner sur notre cloud multi-tenant ou dans le cloud privé d'un client. En bref, nos améliorations internes se sont traduites par un meilleur produit pour certains clients, leur offrant une option Navixy portable et auto-hébergée sans tracas supplémentaire.
Étape 2 : fluidifier le flux de données avec Kafka
L'élément suivant de notre transformation a été l'adoption d'Apache Kafka comme cœur de notre pipeline de données. Bien qu'il ne soit pas strictement requis par Kubernetes, Kafka est devenu un élément clé de notre nouvelle architecture pour gérer la croissance des flux de données. Désormais, tous nos flux de données lourds passent par un cluster Kafka à haut débit dans chaque région. Pourquoi ? Imaginez des centaines de milliers de traceurs GPS qui se reconnectent tous après une panne de réseau - c'est une explosion de données qui frappe soudainement le système. Dans le passé, nous gérions les pics avec une mise en cache ad hoc ou une mise à l'échelle manuelle. Désormais, Kafka agit comme un tampon géant qui atténue les pics de trafic en mettant en file d'attente les données des appareils et en les envoyant à nos microservices à un rythme régulier. La plateforme reste calme et réactive même en cas de "tempête" de messages entrants. Nous appelons Kafka notre "contrôleur aérien" : il veille à ce qu'aucune donnée ne se perde et à ce qu'aucun service ne soit submergé. Cet ajout a amélioré la résilience et a bien découplé nos services (les producteurs et les consommateurs de données sont maintenant mis en mémoire tampon par Kafka). En prime, il prépare le terrain pour de nouvelles fonctionnalités analytiques sur lesquelles nous travaillons, car le fait de disposer d'un flux d'événements central ouvre de nombreuses possibilités. Une fois de plus, c'est un exemple d'adoption d'une technologie industrielle éprouvée pour rendre Navixy plus fort.
Étape 3 : Migration vers Kubernetes (l'événement principal !)
Une fois les bases posées, nous nous sommes attaqués à la migration principale - déplacer tous nos services vers Kubernetes sans aucun temps d'arrêt. Notre équipe DevOps/SRE suit une devise : "ne pas casser ce qui fonctionne". Cela signifie que nous avons abordé cette migration avec beaucoup de soin et de méthode. Nous n'avons pas simplement actionné un interrupteur un jour. Au lieu de cela, nous avons déplacé progressivement des composants dans Kubernetes, en testant au fur et à mesure, sur une période d'environ un an et demi. Pendant un certain temps, nous avons fonctionné de manière hybride, avec certaines parties dans des VM classiques et d'autres dans des K8, en modifiant progressivement l'équilibre. Nous nous sommes constamment demandés "comment pouvons-nous faire cela sans qu'aucun client ne le remarque ?" et nous avons mis en place beaucoup de garde-fous et de surveillance (plus d'informations sur l'observabilité bientôt !) pour nous assurer que nous n'introduisions pas de régressions. Le passage final à Kubernetes a eu lieu au début de l'année 2025, et je suis heureux d'annoncer que nous avons effectué la transition complète sans aucune interruption de service. Pour une plateforme 24/7 qui ingère des données toutes les secondes, ce n'est pas un mince exploit - et je ne pourrais pas être plus fier de notre équipe pour avoir réussi cela. Nous avons essentiellement reconstruit l'avion de Navixy pendant qu'il volait, et aucun passager n'a ressenti la moindre secousse. (Si vous avez l'impression que nous sommes enthousiastes à ce sujet, c'est parce que nous le sommes !)
Tout au long de ce voyage, nous avons également mis à jour notre outil d'observabilité afin de garder un œil sur tout. Nous avons instrumenté la nouvelle plateforme avec Prometheus pour les métriques, Graylog/ELK pour les logs et les tableaux de bord Grafana pour tout visualiser. Il ne s'agissait pas seulement d'une surveillance a posteriori - nous intégrons l'observabilité dans notre processus de développement et de déploiement. En véritable "shift-left", nos ingénieurs utilisent ces outils dans les phases d'essai et de test pour détecter les problèmes à un stade précoce, et pas seulement en production. L'impact de chaque modification du code peut être observé presque immédiatement par le biais de mesures et de journaux, ce qui permet de fermer la boucle de rétroaction pour une amélioration continue. Si quelque chose ne va pas, nous le saurons avant que cela n'affecte un client. En pratique, cela signifie moins de surprises à 3 heures du matin et plus de confiance dans chaque version. (Notre équipe d'astreinte apprécie vraiment cela).
Le résultat : Une plateforme plus solide pour les utilisateurs, les partenaires et les développeurs
Maintenant que la poussière est retombée, quel est le résultat final ? En un mot, le bonheur. L'un de nos ingénieurs a décrit en plaisantant la nouvelle plateforme basée sur Kubernetes comme "un pur bonheur... l'élégance et le contrôle que nous recherchions". Les choses qui étaient difficiles auparavant sont tellement plus faciles aujourd'hui. Permettez-moi de vous présenter quelques résultats et de vous expliquer pourquoi ils sont importants :
- Évolutivité et efficacité à la demande. Notre capacité s'accroît ou se contracte automatiquement en fonction de la charge en temps réel. Si un grand nombre d'appareils commencent soudainement à envoyer des données, Kubernetes démarre plus de pods pour les traiter. Lorsque la charge diminue, il réduit le nombre de pods. Cela permet de maintenir une utilisation élevée des ressources (souvent plus de 80 %) sans surprovisionnement. Nous obtenons essentiellement plus du même matériel. Et ces pics de trafic insensés qui se produisent parfois ? Kafka nous soutient, en mettant en mémoire tampon les rafales afin que l'expérience de l'utilisateur reste stable. Résultat net : des performances constantes et aucune intervention manuelle nécessaire en cas de pic d'utilisation. Nos opérations sont à la fois plus rentables et plus évolutives - une combinaison intéressante.
- Déploiements plus rapides et portée mondiale. L'envoi de mises à jour ou le lancement d'une nouvelle grappe de serveurs est désormais beaucoup plus rapide. Toute modification apportée à la plateforme, où que ce soit dans le monde, n'est qu'à un commit Git et à une exécution du pipeline CI de la production. Dans le passé, le déploiement d'un nouveau nœud régional (par exemple, l'installation de notre plateforme dans un nouveau centre de données pour un client) nécessitait des mois de planification et d'installation artisanale. Aujourd'hui, c'est une question de jours, voire d'heures, et c'est principalement l'automatisation qui fait le travail. Nous avons déjà mis en place de nouveaux clusters Kubernetes dans des régions supplémentaires avec un minimum d'agitation. Cela signifie que Navixy peut s'étendre à de nouvelles régions ou à des clouds privés de clients très rapidement, ce qui constitue un avantage concurrentiel important à mesure que nos activités mondiales se développent. En bref, nous pouvons évoluer horizontalement sans les maux de tête habituels. Notre architecture multirégionale (avec des clusters en Europe, en Amérique du Nord, etc.) est plus facile à étendre et à gérer que jamais.
- Haute disponibilité dès la conception. Kubernetes, combiné à notre configuration multi-centres de données et multi-régions, a porté notre haute disponibilité à un niveau supérieur. Chacun de nos clusters régionaux s'étend sur 2 ou 3 centres de données avec une distribution de charge automatisée. Si un centre de données entier tombe en panne (on frappe du bois), Kubernetes déplace les charges de travail vers les autres - les utilisateurs ne le remarqueront même pas. Nous avons essentiellement intégré le basculement vers le cloud dans notre ADN. Notre page d'état publique(status.navixy.com) reflète cette résilience ; des problèmes peuvent survenir dans une zone, mais le système dans son ensemble reste opérationnel. Cette architecture nous a permis d'atteindre notre objectif de 99,99 % de temps de disponibilité de manière constante. Ce n'est pas que de la théorie : nous avons vu Kubernetes reprogrammer rapidement les charges de travail lors d'incidents réels, évitant ainsi les temps d'arrêt. Pour les clients, cela signifie que Navixy est là quand vous en avez besoin, point final.
- Modularité et maintenabilité. La décomposition de la plateforme en microservices a rendu son développement et sa maintenance beaucoup plus faciles. Chaque service (traitement des données GPS, géocodage, rapports, etc.) peut être travaillé indépendamment et déployé selon son propre calendrier. Si nous voulons mettre à jour le module de rapports, nous pouvons déployer ce conteneur seul sans toucher aux autres. Si quelque chose ne fonctionne pas correctement, Kubernetes peut isoler et annuler uniquement cette partie, sans aucun impact sur le reste du système. Ce type d'isolation constitue une amélioration considérable par rapport à l'époque où un seul bogue pouvait entraîner l'effondrement d'une application monolithique. Pour nos partenaires développeurs qui utilisent les API de Navixy, cette modularité signifie que les services sur lesquels ils s'appuient sont plus fiables et peuvent évoluer plus rapidement. En interne, elle nous aligne également sur les meilleures pratiques cloud-natives utilisées par les leaders de la technologie - comme Netflix ou Uber qui gèrent leurs systèmes. Nous avons essentiellement mis à l'épreuve le design de la plateforme Navixy.
Il est important de noter que ces progrès n'ont pas été réalisés en augmentant massivement la main-d'œuvre pour résoudre le problème. Navixy est encore une équipe relativement petite et intelligente (~100 professionnels) qui porte plusieurs chapeaux. Nous n'avons pas le luxe d'avoir des centaines d'ingénieurs, mais avec la bonne automatisation et la culture DevOps, nous n'avons pas besoin d'en avoir autant. L'ensemble du projet Kubernetes a été un travail d'amour pour notre équipe DevOps et d'ingénierie, et il montre ce qu'une équipe agile peut accomplir. (J'aime à penser que nous frappons au-dessus de notre poids ! 🥊) En fait, notre expérience reflète des tendances sectorielles plus larges : une étude de cas bien connue a noté que la plateforme IoT de Bose gérait 30 000 déploiements par an sur des dizaines de microservices avec une centaine d'ingénieurs, grâce à Kubernetes et à l'automatisation. Nous voyons le même principe à l'œuvre ici - avec GitOps, CI/CD et Kubernetes, une équipe réduite peut gérer une infrastructure à grande échelle, distribuée à l'échelle mondiale, sans transpirer. Il s'agit de travailler plus intelligemment, en tirant parti des logiciels et des outils cloud pour amplifier ce que nos collaborateurs peuvent faire. L'enthousiasme et la précision que notre équipe a apportés à ce projet ont fait toute la différence.
Enfin, qu'est-ce que tout cela signifie pour vous, nos partenaires, nos développeurs et nos clients ? Concrètement, Navixy est aujourd'hui une plateforme plus conviviale que jamais pour les développeurs. Si vous créez des solutions télématiques sur nos API ou si vous intégrez des appareils, vous pouvez être sûr que le backend est moderne et évolutif. Nous sommes en mesure de vous fournir de nouvelles fonctionnalités et améliorations plus rapidement, avec moins de risques. Et si vous avez des besoins de déploiement uniques (par exemple, une installation sur site pour un projet sensible), notre approche conteneurisée vous couvre. La plateforme Navixy peut fonctionner dans notre nuage ou dans le vôtre avec la même facilité, ce qui ouvre des possibilités de collaboration et de solutions personnalisées. Nous avons déjà eu des partenaires de distribution qui ont profité de notre édition Dockerisée sur site pour servir des clients qui exigent une résidence stricte des données - ce qui n'était tout simplement pas faisable auparavant. En bref, la plateforme est plus flexible pour toutes les parties concernées.
Alors que nous terminons ce voyage, il est clair que l'adoption de Kubernetes était plus qu'une simple mise à niveau technique - c'était un mouvement stratégique vers une Navixy plus modulaire, plus évolutive et plus agile. Nous avons modernisé notre architecture et nos processus en même temps, des pipelines d'intégration continue à l'observabilité et tout ce qui se trouve entre les deux. Le résultat est une plateforme prête pour l'avenir de la télématique, soutenue par une équipe enthousiaste à l'idée de continuer à repousser les limites.
À notre incroyable équipe DevOps et d'ingénierie : bravo ! Il s'agissait d'un projet complexe que vous avez géré avec enthousiasme et compétence, et nous sommes sortis plus forts de l'autre côté. 🎉 Et à nos clients et partenaires : merci de nous avoir fait confiance tout au long de cette évolution. Le plus beau, c'est que la plupart de ces changements ont eu lieu en coulisses et que vous venez, je l'espère, de faire l'expérience d'un Navixy plus rapide et encore plus fiable. C'est exactement ce qu'il faut faire.
Nous espérons que cet aperçu des coulisses vous a permis de comprendre comment la petite équipe de Navixy exploite les grandes technologies pour offrir une plateforme de classe mondiale. La conversation autour de l'infrastructure cloud est en constante évolution - les mots à la mode tels que plateformes de développeurs internes, GitOps, et observabilité shift-left ne sont pas que des mots à la mode pour nous ; ce sont des principes que nous avons mis en pratique pour construire un meilleur service. Kubernetes est désormais au cœur de notre histoire, et nous sommes ravis de la base qu'il fournit pour les années à venir. Il reste encore beaucoup à faire (dans le domaine de la technologie, c'est toujours le cas !), mais avec cette architecture en place, nous sommes confiants et prêts à affronter la suite.
Merci de votre lecture ! Nous vous souhaitons un avenir aussi dynamique et fiable que l'infrastructure que nous avons mise en place. Si vous avez des questions ou des idées, ou si ce type de travail vous passionne, n'hésitez pas à nous contacter. Après tout, nous ne construisons pas seulement une plateforme, nous la construisons avec une communauté d'innovateurs. Bon suivi ! 🚀
- Qu'est-ce qui a changé dans notre plateforme ?
- Reconstruire notre infrastructure (sans perdre de temps)
- Étape 1 : GitOps et CI/CD - Préparer le terrain
- Étape 2 : fluidifier le flux de données avec Kafka
- Étape 3 : Migration vers Kubernetes (l'événement principal !)
- Le résultat : Une plateforme plus solide pour les utilisateurs, les partenaires et les développeurs
