Według relacji technicznej opublikowanej przez AWS 29 października 2026 r. BMW Connected Company rozpoczęło w 2024 r. migrację Orbit, platformy usług dla połączonych pojazdów, z x86 na oparty na Arm AWS Graviton. Współautorzy z BMW Group i Critical TechWorks opisali etapowe wdrożenie, w którym obok węzłów Graviton nadal działały węzły x86.
Co BMW Connected Company przenosiło na Graviton?
Orbit to wewnętrzna nazwa platformy Connected Vehicle rozwijanej i obsługiwanej przez BMW Connected Company, oddział BMW Group. Relacja podaje, że w chwili publikacji ponad 65% platformy działało na Graviton w środowiskach produkcyjnych.
Według współautorów platforma CI/CD obsługiwała ponad 130 000 kompilacji i wdrożeń dziennie za pośrednictwem własnych runnerów GitHub Actions. Przy takiej skali zmiana architektury wymagała sposobu na stopniowe włączanie obciążeń, bez jednoczesnego przełączania całej platformy.
Jak współistniały x86 i Arm?
BMW utrzymywało potoki kompilacji dla obu architektur i przygotowywało wieloarchitekturowe obrazy kontenerów. Indeks OCI zawiera warianty obrazu dla arm64 i amd64, dzięki czemu ten sam tag może obsługiwać obie architektury, a środowisko uruchomieniowe wybiera właściwy wariant.
Zespoły mogły budować obrazy na runnerach dopasowanych do danej architektury albo używać Docker Buildx z emulacją QEMU. Natywne kompilacje na runnerach Graviton omijały narzut emulacji; QEMU ułatwiało budowanie dla kilku architektur z jednego runnera, ale mogło spowalniać zadania intensywnie wykorzystujące moc obliczeniową.
W przypadku Amazon EKS, platformy Kubernetes, Karpenter zastąpił stałe Managed Node Groups dynamicznymi pulami węzłów zarządzanymi według polityk. Publiczne obrazy kopiowano do prywatnego Amazon ECR za pomocą Google Crane, które filtrowało manifesty, pozostawiając warianty potrzebne dla obsługiwanych platform.
Jak zespoły włączały obciążenia do Graviton?
Pule węzłów Graviton były współdzielone, ale ich użycie wymagało świadomego włączenia obciążenia. Kubernetes stosował tainty, selektory węzłów i tolerancje: do puli Arm trafiały obciążenia oznaczone jako gotowe na tę architekturę. Reguły affinity mogły preferować Arm, lecz nie wymuszały takiego przydziału. Obciążenia nieprzeniesione nadal mogły działać na węzłach x86.
Migracja zaczynała się od testów usług samodzielnych, po których zespół sprawdzał podstawowe usługi platformy, w tym Karpenter, Prometheus i narzędzia operacyjne. Dopiero potem zachęcał zespoły aplikacyjne do przenoszenia kolejnych obciążeń.
Projekt zakładał też możliwość powrotu do x86. Obrazy obsługujące obie architektury i dostępne pule x86 pozwalały uruchomić obciążenie na dotychczasowej architekturze. W modelu GitOps ArgoCD mogło odtworzyć wcześniejszą wersję konfiguracji z Git i ponownie uzgodnić z nią stan klastra.
Jakie wyniki podali współautorzy?
Współautorzy przypisali migracji oszczędności infrastrukturalne w ujęciu rocznym, a konkretne wyniki wydajnościowe kontrolerowi ingress NGINX, czyli komponentowi kierującemu ruchem przychodzącym do usług. Te miary dotyczą różnych aspektów wdrożenia.
| Miara | Wynik podany przez współautorów | Zakres |
| Oszczędności infrastrukturalne | Około 600 tys. USD rocznie, w ujęciu annualizowanym | Opisana migracja Orbit |
| Zużycie CPU | Około 57% niższe | Kontroler ingress NGINX po przejściu z x86 na Graviton, przy zachowaniu tego samego profilu ingress |
| Stosunek wydajności do ceny | Około 40% lepszy | Opisane porównanie kontrolera ingress; współautorzy powiązali wynik z mniejszym zużyciem CPU na żądanie i większą przepustowością na dolara |
| Udział Graviton w platformie | Ponad 65% | Platforma Orbit w środowiskach produkcyjnych w chwili publikacji relacji |
