BMW Connected Company ha iniziato nel 2024 a migrare Orbit, la sua piattaforma Connected Vehicle, dai processori x86 ad AWS Graviton, basato su Arm. Il resoconto tecnico pubblicato da AWS il 29 ottobre 2026 è stato scritto insieme a rappresentanti di BMW Group e Critical TechWorks: i coautori riferiscono risparmi e miglioramenti di prestazioni per ambiti specifici della piattaforma.
La migrazione riguarda la piattaforma Orbit
Orbit è la piattaforma per i servizi digitali connessi di BMW Connected Company, divisione di BMW Group. Il cambiamento descritto riguarda questa piattaforma: i coautori riferiscono che, al momento della pubblicazione, oltre il 65% di Orbit funzionava su Graviton negli ambienti di produzione.
La piattaforma CI/CD, cioè quella usata per integrare e distribuire software, gestiva più di 130.000 build e deployment al giorno tramite runner autogestiti di GitHub Actions. Per spostare carichi di lavoro senza imporre un passaggio simultaneo a una sola architettura, il piano manteneva in uso sia x86, detta anche amd64, sia Arm, detta anche arm64.
Immagini multi-architettura e build parallele
Il sistema di build produceva immagini per entrambe le architetture. Un indice OCI può raccogliere le varianti arm64 e amd64 sotto lo stesso riferimento: quando un container viene avviato, il sistema seleziona l’immagine adatta al nodo su cui deve girare.
Per creare le immagini, BMW usava sia runner nativi per ciascuna architettura sia Docker Buildx con QEMU, un emulatore. I runner nativi evitano l’overhead dell’emulazione; QEMU consente invece di costruire immagini multi-architettura da un solo runner, ma può rallentare le build che richiedono molto calcolo. La scelta permette di privilegiare la velocità quando serve, senza rinunciare a un percorso di build più semplice.
I team potevano scegliere quando spostare i workload
I nodi Graviton erano disponibili in pool condivisi, ma il loro uso era opt-in. In Kubernetes, taint, selettori e tolleranze limitavano il posizionamento sui nodi Arm ai workload predisposti per quell’architettura. La preferenza di scheduling poteva favorire Arm senza obbligare ogni applicazione a migrare; i nodi x86 restavano disponibili.
Il piano comprendeva anche un percorso di ritorno: immagini compatibili con entrambe le architetture e nodi x86 potevano consentire il fallback senza ricostruire le immagini o modificare le pipeline. Per il ripristino dello stato del cluster, il modello GitOps descritto usava ArgoCD per tornare a una versione precedente del repository e riallineare il cluster.
I risultati dichiarati dai coautori
I coautori hanno riportato risultati distinti per i costi dell’infrastruttura, il controller di ingresso NGINX e la quota di adozione di Graviton. Le percentuali relative al controller si riferiscono al confronto descritto a parità di profilo di ingresso.
| Misura | Risultato dichiarato | Ambito |
| Risparmi annualizzati sull’infrastruttura | Circa 600.000 dollari statunitensi all’anno | Migrazione della piattaforma |
| Consumo di CPU del controller di ingresso NGINX | Circa il 57% in meno | Stesso profilo di ingresso dopo il passaggio da x86 a Graviton |
| Rapporto prestazioni/prezzo del controller di ingresso | Circa il 40% in più | Risultato riferito al confronto sul controller di ingresso |
| Adozione di Graviton | Oltre il 65% | Quota di Orbit in esecuzione su Graviton negli ambienti di produzione al momento della pubblicazione |
