BMW Connected Company begann 2024, Orbit, seine Plattform für vernetzte Fahrzeuge, von x86 auf Arm-basierte Rechenleistung mit AWS Graviton umzustellen. Der technische Bericht dazu erschien am 29. Oktober 2026. Er beschreibt eine schrittweise Migration, bei der x86 und Arm parallel liefen und Teams ihre Anwendungen einzeln umstellen konnten.
Was BMW Connected Company umstellte
Orbit ist der interne Name der Connected-Vehicle-Plattform von BMW Connected Company, einer Sparte der BMW Group. Die Migration betraf diese Plattform. Die Co-Autoren bezifferten den Anteil, der zum Zeitpunkt der Veröffentlichung in Produktionsumgebungen auf Graviton lief, auf mehr als 65 Prozent.
Die Dimension des Betriebs: Die digitalen Dienste von BMW Connected Company unterstützen laut den Co-Autoren eine weltweite Flotte von mehr als 24,5 Millionen Fahrzeugen. Die CI/CD-Plattform, also die Infrastruktur für fortlaufendes Bauen und Bereitstellen von Software, bewältigt demnach täglich mehr als 130.000 Builds und Deployments über selbst gehostete GitHub-Actions-Runner.
Wie x86 und Arm parallel liefen
BMW setzte auf Container-Images für beide Prozessorarchitekturen. Ein OCI-Image-Index kann Varianten für Arm64 und AMD64 bündeln; die Laufzeitumgebung wählt dann die passende Version für den jeweiligen Knoten. So konnten Anwendungen auf beiden Architekturen laufen, ohne dass jedes Team eine separate Image-Adresse verwalten musste.
Für den Bau dieser Images beschreibt der Bericht zwei Wege: native Runner, die jeweils auf der passenden Architektur arbeiten, und Docker Buildx mit QEMU-Emulation. Native Graviton-Runner vermeiden den Emulationsaufwand. QEMU kann Builds von einem einzelnen Runner aus vereinfachen, kann aber rechenintensive Aufgaben verlangsamen.
Wie Teams ihre Anwendungen schrittweise umstellten
Die Graviton-Knotenpools in Amazon EKS waren für Anwendungen ausgelegt, die für Arm bereit waren. Kubernetes-Taints sperrten die Knoten für andere Workloads; ein passender Node-Selector und eine Toleration erlaubten einer Anwendung den Zugriff. Eine Affinitätsregel bevorzugte Arm, erzwang die Platzierung dort aber nicht. Anwendungen konnten weiter auf x86-Knoten laufen.
Der beschriebene Ablauf begann mit eigenständigen Diensten und führte anschließend zu zentralen Plattformdiensten und Werkzeugen, darunter Karpenter und Prometheus. Damit mussten Teams ihre Anwendungen nicht gleichzeitig umstellen. Für einen Rückfall blieb die x86-Infrastruktur verfügbar; ArgoCD konnte nach dem Zurücksetzen auf einen früheren Git-Stand den Clusterzustand wieder mit der Konfiguration abgleichen.
Welche Ergebnisse die Co-Autoren meldeten
Die Co-Autoren bezifferten die annualisierten Infrastrukturersparnisse auf rund 600.000 US-Dollar. Für den NGINX-basierten Ingress-Controller meldeten sie bei unverändertem Ingress-Profil rund 57 Prozent weniger CPU-Verbrauch und eine um etwa 40 Prozent bessere Preis-Leistung.
| Kennzahl | Gemeldeter Wert | Geltungsbereich |
| Annualisierte Infrastrukturersparnis | Rund 600.000 US-Dollar pro Jahr | Infrastruktur der Orbit-Migration |
| CPU-Verbrauch | Rund 57 Prozent geringer | NGINX-basierter Ingress-Controller bei gleichem Ingress-Profil |
| Preis-Leistung | Rund 40 Prozent besser | Der beschriebene Ingress-Vergleich |
| Graviton-Anteil | Mehr als 65 Prozent | Orbit in Produktionsumgebungen zum Zeitpunkt der Veröffentlichung |
Die vier Werte beschreiben unterschiedliche Aspekte der Orbit-Migration. Der Graviton-Anteil bezieht sich auf die Plattform in Produktionsumgebungen; die beiden Leistungswerte gelten für den beschriebenen Ingress-Controller. Die Co-Autoren stellten außerdem eine effizientere Skalierung bei Spitzenlast fest, nannten dafür aber keinen Zahlenwert.
