A BMW Connected Company começou em 2024 a migrar a plataforma de veículos conectados Orbit de x86 para o AWS Graviton, baseado em Arm. O relato técnico publicado pela AWS em 29 de outubro de 2026, coescrito com representantes da BMW Group e da Critical TechWorks, descreve uma transição gradual que manteve as duas arquiteturas em operação.
O que a BMW migrou para o Graviton
A Orbit é a plataforma de veículos conectados da BMW Connected Company, divisão da BMW Group. A migração descrita no relato se refere a essa plataforma, não a todos os serviços da BMW. Na publicação de 29 de outubro de 2026, os coautores afirmaram que mais de 65% da Orbit rodava em Graviton nos ambientes de produção.
A escala ajuda a entender por que a transição foi feita por etapas: a BMW Connected Company opera serviços digitais para uma frota mundial de mais de 24,5 milhões de veículos, e a plataforma de integração e entrega contínuas (CI/CD) processa mais de 130 mil compilações e implantações por dia, segundo o relato.
Como x86 e Arm funcionaram lado a lado
A estratégia combinou pipelines de compilação para as duas arquiteturas com imagens de contêiner compatíveis com arm64 e amd64. Um índice OCI reúne as versões de cada arquitetura sob a mesma referência; ao executar a imagem, o ambiente seleciona a variante adequada ao nó. Assim, as equipes podiam adotar o Graviton sem deixar de atender cargas que continuavam em x86.
Para criar essas imagens, a equipe podia usar executores nativos de cada arquitetura ou compilar com Docker Buildx e emulação QEMU. Executores nativos evitam a sobrecarga da emulação. O QEMU permite compilar para outra arquitetura a partir de um único executor, mas pode tornar mais lentas as tarefas que exigem muito processamento.
A migração das cargas ficou a critério das equipes
Os nós Graviton ficavam em grupos compartilhados, mas a alocação era optativa. No Kubernetes, taints restringem quais cargas podem ser agendadas nesses nós; a equipe precisava indicar que uma aplicação estava pronta para Arm com um seletor de nó e a tolerância correspondente. A afinidade de nós podia dar preferência ao Arm sem obrigar a aplicação a usá-lo, enquanto os nós x86 continuavam disponíveis.
O desenho também previa caminhos de retorno. Imagens multi-arquitetura e nós x86 permitiam voltar a executar uma carga nessa arquitetura. Com GitOps e ArgoCD, a equipe podia reverter para uma versão anterior no Git e reconciliar o estado do cluster. O relato descreve esses recursos como parte da estratégia de implantação.
Os resultados divulgados pelos coautores
Os coautores informaram os resultados abaixo para a migração da Orbit. As métricas tratam de aspectos diferentes: economia anualizada, uso de CPU e relação entre preço e desempenho do controlador de entrada NGINX, além da parcela da plataforma em Graviton.
| Métrica | Resultado divulgado | Escopo |
| Economia anualizada de infraestrutura | Aproximadamente US$ 600 mil por ano | Resultado atribuído à migração da Orbit |
| Consumo de CPU do controlador de entrada NGINX | Cerca de 57% menor | Após a mudança de x86 para Graviton, mantendo o mesmo perfil de entrada |
| Relação preço-desempenho do controlador de entrada NGINX | Cerca de 40% melhor | Resultado associado à comparação do controlador de entrada |
| Adoção do Graviton | Mais de 65% | Parcela da Orbit em Graviton nos ambientes de produção, conforme o relato de 29 de outubro de 2026 |
