BMW Connected Company a commencé en 2024 à migrer Orbit, sa plateforme de véhicules connectés, des processeurs x86 vers AWS Graviton, fondé sur l’architecture Arm. L’entreprise a fait coexister les deux architectures pendant la transition : les équipes pouvaient adopter Graviton charge de travail par charge de travail, tandis que des nœuds x86 restaient disponibles.
Le périmètre de la migration d’Orbit
Orbit est le nom interne de la plateforme Connected Vehicle de BMW Connected Company, une division de BMW Group. Dans un récit technique publié par AWS le 29 octobre 2026, Tomislav Lozancic et Hrvoje Lukavski, de BMW Group, ainsi que Hugo Cardoso, de Critical TechWorks, décrivent une migration progressive vers AWS Graviton. À la date de publication du récit, ses coauteurs indiquaient que plus de 65 % de la plateforme fonctionnait sur Graviton dans les environnements de production.
La plateforme soutient des services numériques destinés à un parc mondial de plus de 24,5 millions de véhicules, selon ce même récit. Son infrastructure d’intégration et de déploiement continus, ou CI/CD, traitait plus de 130 000 builds et déploiements par jour grâce à des runners GitHub Actions hébergés par BMW. Ces volumes donnent une idée de l’échelle opérationnelle d’Orbit, sans modifier le périmètre des résultats annoncés pour certaines charges précises.
Builds et conteneurs compatibles avec x86 et Arm
BMW a travaillé sur deux volets : les pipelines de build et l’hébergement des conteneurs. Une image multi-architecture peut contenir des variantes amd64 et arm64 sous une même référence. L’index OCI associé permet à l’environnement d’exécution de choisir la variante correspondant au processeur du nœud.
Pour produire ces images, les équipes pouvaient utiliser des runners natifs adaptés à chaque architecture ou Docker Buildx avec l’émulateur QEMU. Un runner natif évite le surcoût de l’émulation ; QEMU peut simplifier certains pipelines en permettant de compiler depuis un seul runner, mais ralentir les builds exigeants en calcul.
Le récit décrit également la mise en miroir d’images publiques vers un registre privé Amazon ECR avec Google Crane, qui filtre les variantes afin de ne conserver que les architectures nécessaires. Ce travail sur les images permettait de faire cohabiter les deux types de nœuds sans imposer aux équipes une bascule simultanée.
Un placement des charges choisi par les équipes
Les pools de nœuds Graviton partagés étaient accessibles sur inscription volontaire. Dans Kubernetes, des taints empêchent par défaut une charge de s’installer sur un pool donné ; un sélecteur de nœud et une tolération indiquent qu’une charge est prête à y être placée. Les charges qui n’avaient pas encore adopté Arm pouvaient rester sur des nœuds amd64. Une règle d’affinité privilégiait Arm sans rendre ce placement obligatoire.
La migration s’est appuyée sur une validation par étapes : les équipes ont d’abord essayé des services autonomes, puis des composants de la plateforme, dont Karpenter, Prometheus et des outils opérationnels. Karpenter, qui provisionne les nœuds selon des politiques, remplaçait les groupes de nœuds gérés fixes décrits dans le récit.
Les images multi-architecture et la disponibilité de nœuds x86 faisaient partie des solutions de repli décrites. Le déploiement GitOps avec ArgoCD permettait aussi de revenir à une version antérieure du dépôt Git, puis de réconcilier l’état du cluster avec cette version.
Les résultats annoncés par les coauteurs
Les chiffres rapportés portent sur des mesures distinctes. Les économies concernent l’infrastructure de la migration ; les résultats CPU et performance-prix sont liés au contrôleur d’ingress NGINX ; la part d’adoption concerne la plateforme Orbit en production.
| Mesure | Résultat rapporté | Périmètre |
| Économies d’infrastructure annualisées | Environ 600 000 dollars américains | Migration d’Orbit |
| Consommation CPU | Environ 57 % de moins | Contrôleur d’ingress NGINX après le passage de x86 à Graviton, à profil d’ingress identique |
| Rapport performance-prix | Amélioration d’environ 40 % | Résultat associé au contrôleur d’ingress NGINX |
| Adoption de Graviton | Plus de 65 % | Part de la plateforme fonctionnant sur Graviton dans les environnements de production à la date du récit |
La baisse de consommation CPU et l’amélioration du rapport performance-prix décrivent le même cas d’usage NGINX, tandis que les économies annualisées et la part de la plateforme sur Graviton répondent à d’autres questions. Les coauteurs attribuent ainsi les gains mesurés à leurs périmètres respectifs, sans les étendre à l’ensemble des charges BMW.
