BMW Connected Company begon in 2024 met de migratie van Orbit, zijn platform voor verbonden voertuigen, van x86 naar Arm-gebaseerde AWS Graviton. De gefaseerde aanpak hield beide architecturen beschikbaar. In een op 29 oktober 2026 door AWS gepubliceerd technisch account, mede geschreven door vertegenwoordigers van BMW Group en Critical TechWorks, melden de coauteurs besparingen en prestatiecijfers voor specifieke onderdelen van de migratie.
Wat BMW naar Graviton migreerde
Orbit is de interne naam voor het Connected Vehicle-platform van BMW Connected Company, een divisie van BMW Group. Volgens de coauteurs draaide op het moment van publicatie meer dan 65% van het platform in productieomgevingen op Graviton. De casus gaat daarmee over Orbit, niet over alle BMW-diensten.
De schaal van het platform maakt duidelijk waarom de overgang stapsgewijs verliep. BMW Connected Company beheert digitale diensten voor een wereldwijd wagenpark van meer dan 24,5 miljoen voertuigen. Het CI/CD-platform voor Connected Vehicles verwerkte dagelijks meer dan 130.000 builds en deployments via zelfbeheerde GitHub Actions-runners.
Hoe x86 en Arm naast elkaar bleven werken
BMW bouwde ondersteuning voor beide architecturen in de buildstraat en in de containeromgeving in. Een multi-architectuurimage bevat varianten voor zowel arm64 als amd64. Via een OCI-image-index kan dezelfde imagetag op beide typen nodes worden gebruikt; de runtime kiest de passende variant.
Voor builds gebruikten de teams architectuurspecifieke runners en Docker Buildx met QEMU-emulatie. Een native runner bouwt rechtstreeks voor de doelarchitectuur en vermijdt de overhead van emulatie. QEMU kan builds vanaf één runner vereenvoudigen, maar kan rekenintensief werk vertragen. Het account beschrijft ook hoe openbare images met Google Crane naar een private Amazon ECR-registry werden gespiegeld, met alleen de benodigde architectuurvarianten.
Hoe teams workloads konden overzetten
De Graviton-nodepools waren opt-in. Kubernetes-taints, node-selectors en bijpassende tolerations zorgden ervoor dat alleen workloads die klaar waren voor Arm op die pools konden worden ingepland. Node affinity gaf de voorkeur aan Arm zonder plaatsing daar af te dwingen; workloads konden op amd64 blijven draaien.
De beschreven terugvalroute gebruikte multi-architectuurimages en beschikbare x86-nodes. Voor GitOps-deployments kon ArgoCD een eerdere Git-versie herstellen en de clusterstatus daarmee weer in overeenstemming brengen. Dat gaf teams een manier om de overgang per workload te beheren, terwijl de bestaande x86-omgeving beschikbaar bleef.
Welke resultaten de coauteurs meldden
De coauteurs rapporteerden verschillende uitkomsten voor de migratie. De CPU- en prijs-prestatiecijfers hieronder hebben betrekking op de NGINX-ingresscontroller bij hetzelfde ingressprofiel.
| Maatstaf | Gerapporteerd resultaat | Reikwijdte |
| Infrastructuurbesparing | Circa 600.000 Amerikaanse dollar per jaar | Geannualiseerde besparing voor de migratie |
| CPU-verbruik | Circa 57% lager | NGINX-ingresscontroller na de overstap van x86 naar Graviton, bij hetzelfde ingressprofiel |
| Prijs-prestatie | Circa 40% beter | Het beschreven ingressresultaat, gekoppeld aan lager CPU-verbruik per request en meer throughputcapaciteit per dollar |
| Graviton-adoptie | Meer dan 65% | Aandeel van het platform dat op het moment van publicatie in productieomgevingen op Graviton draaide |
De 57% beschrijft de verandering in CPU-verbruik; de prijs-prestatiemaat gaat over throughputcapaciteit per dollar. Het zijn dus afzonderlijke resultaten voor de beschreven ingress-workload. De geannualiseerde besparing en het aandeel van het platform zijn weer andere maatstaven.
