BMW Connected Company empezó en 2024 a migrar Orbit, su plataforma de vehículos conectados, de x86 a la computación Arm de AWS Graviton. El relato técnico que AWS publicó el 29 de octubre de 2026, coescrito por Tomislav Lozancic y Hrvoje Lukavski, de BMW Group, y Hugo Cardoso, de Critical TechWorks, describe una transición gradual en la que convivieron ambas arquitecturas.
Qué abarcó la migración
Orbit es el nombre interno de la plataforma Connected Vehicle de BMW Connected Company, una división de BMW Group. El cambio descrito fue de x86, también denominado amd64, a Arm, cuya variante para estos sistemas se conoce como arm64. En el momento de publicación del relato, sus coautores indicaron que más del 65% de la plataforma funcionaba con Graviton en entornos de producción.
La plataforma procesaba más de 130.000 compilaciones y despliegues diarios mediante ejecutores autoalojados de GitHub Actions. Para que los equipos pudieran adoptar Arm por etapas, el enfoque combinó compilaciones preparadas para ambas arquitecturas con la posibilidad de ejecutar contenedores en nodos Graviton.
Cómo convivieron Arm y x86
Las imágenes de contenedor podían incluir variantes arm64 y amd64 bajo una misma referencia. Un índice OCI permite que el entorno elija la variante correspondiente al tipo de nodo, de modo que la plataforma pueda mantener imágenes para las dos arquitecturas.
BMW empleó compilaciones nativas en ejecutores de la arquitectura de destino y Docker Buildx con emulación QEMU. Las compilaciones nativas evitan la sobrecarga de emular otra arquitectura; la emulación permite compilar para varias arquitecturas desde un único ejecutor, pero puede ralentizar tareas de cálculo intensivo.
Cómo se asignaban las cargas de trabajo
Los equipos podían optar por los grupos compartidos de nodos Graviton cuando sus cargas estaban preparadas para Arm. En Kubernetes, las taints reservaban esos nodos para cargas que declarasen el selector y la toleration correspondientes. La afinidad de nodos podía favorecer Arm sin forzar la asignación, mientras los nodos x86 seguían disponibles.
El relato también describe una vía de reversión basada en imágenes multi-arquitectura y nodos x86. Con ArgoCD, el sistema podía recuperar una versión anterior de Git y volver a sincronizar el estado del clúster. Son medidas descritas para el diseño de la migración.
Qué resultados comunicaron los coautores
Los coautores atribuyeron a la migración un ahorro anualizado de infraestructura y comunicaron resultados específicos para el controlador de ingreso basado en NGINX. Un controlador de ingreso gestiona el tráfico que entra en los servicios. En ese caso, la comparación mantuvo el mismo perfil de ingreso; las cifras no describen una medición común para cada carga de Orbit.
| Medida | Resultado comunicado | Alcance |
| Ahorro anualizado de infraestructura | Aproximadamente 600.000 dólares estadounidenses | Ahorro anualizado atribuido a la migración |
| Consumo de CPU | Aproximadamente un 57% menos | Controlador de ingreso NGINX, con el mismo perfil de ingreso |
| Rendimiento por precio | Alrededor de un 40% mejor | Resultado comunicado para el controlador de ingreso |
| Adopción de Graviton | Más del 65% | Parte de Orbit que funcionaba en Graviton en entornos de producción al publicarse el relato |
Las cifras corresponden a medidas distintas: ahorro de infraestructura, consumo de CPU y rendimiento por precio del controlador NGINX, y proporción de Orbit que utilizaba Graviton en producción.
