Google ha dado un paso de gigante en su estrategia multi-arquitectura. Tras el anuncio de Axion, sus primeros CPUs Arm® diseñados a medida, la compañía ha explicado cómo ha conseguido que decenas de miles de aplicaciones internas se compilen y se ejecuten simultáneamente en x86 y en ARM dentro de sus clústeres de producción. No es un experimento: YouTube, Gmail o BigQuery ya sirven tráfico en ambas ISAs en paralelo, con hardware Arm saturado de uso y más servidores desplegándose cada mes.
El incentivo es claro. Según datos de Google, las instancias basadas en Axion ofrecen hasta un 65 % mejor precio-rendimiento y son hasta un 60 % más eficientes energéticamente frente a instancias comparables dentro de Google Cloud. Llevado a escala de centro de datos, esa mejora multiplica el impacto: menor factura energética y más capacidad utilizable por vatio para clientes y servicios de primera parte.
Migrar a “multiarch” a escala de almacén: lo que no fue el problema
El relato técnico desmonta algunas suposiciones frecuentes. Antes de empezar, tanto el equipo multiarch como los equipos de aplicación asumían que las grandes piedras serían las diferencias de arquitectura: deriva en coma flotante, concurrencia, intrinsics vectoriales, operadores específicos, o brechas de rendimiento difíciles de cerrar. No fue así —o, al menos, no en la magnitud esperada—.
En las primeras migraciones de servicios “top” (como F1, Spanner o Bigtable), los ingenieros encontraron casos reales de esas diferencias, pero muchos menos de lo previsto. Las herramientas modernas —compiladores y sanitizers— habían “sacado a la luz” una buena parte de los sustos con el paso de los años. La mayor fricción estaba en otro sitio:
- Tests sobreajustados a x86 que asumían timings o detalles de plataforma.
- Sistemas de build y release muy antiguos que no contemplaban variantes Arm.
- Configuraciones de despliegue que no entendían un mismo servicio corriendo en dos ISAs.
- Riesgo operativo al tocar sistemas críticos en producción.
Un ingeniero lo sintetizó así: “Todo el mundo se obsesionó con la toolchain totalmente diferente, y ‘seguro que todo se rompe’. La mayor parte de la dificultad fue configs y cosas aburridas”.
El reto no era migrar “los grandes”: era el long tail
Mover una docena de jobs críticos con squads dedicados y reuniones semanales funciona, pero no escala. Aunque aproximadamente el 60 % del cómputo en ejecución está en las 50 aplicaciones más grandes, en un monorepo con más de 100.000 aplicaciones el uso del resto queda en una “larga cola” bastante plana. Si la meta es que Borg (el orquestador interno) encaje los trabajos eficientemente en celdas con x86 y Arm, cuantos más jobs sean multiarch, mejor. La única forma viable: automatización.
Google lo aborda con un conjunto de herramientas —algunas ya muy usadas antes del proyecto— y con un agente de IA de nueva hornada para cerrar la brecha.
Automatización: commits masivos, validación y despliegues sin “mano humana”
- Rosie: genera commits a gran escala y los “pastorea” por el flujo de revisión. Ejemplo: activar el modo Arm en el Blueprint de un job con una línea de configuración.
- Sanitizers y fuzzers: detectan diferencias de ejecución entre x86 y Arm antes de llegar a producción (por ejemplo, data races ocultas por el modelo de memoria TSO de x86), evitando comportamientos no deterministas en la recompilación.
- CHAMP (Continuous Health Monitoring Platform): marco automatizado para desplegar y monitorizar jobs multiarch. Si un job crashea en Arm o baja el throughput, se evacua automáticamente para afinado offline, sin arriesgar la salud del clúster.
Con estos mimbres, el equipo empezó a “industrializar” la migración.
38.156 commits y tres fases: tooling, código, configuración
Para entender qué clase de cambios exigía la migración a escala, Google analizó 38.156 commits en su monorepo Google3 —en total, unos 700.000 líneas cambiadas—. Con Gemini Flash y una ventana de 1 millón de tokens, clasificó los cambios en 16 categorías agrupadas en cuatro grandes bloques y trazó su evolución temporal:
- Herramientas y adaptación de tests: al poner en marcha la toolchain multiarch, la gran mayoría de commits fueron ajustes de tooling y tests.
- Adaptación de código: en la migración de las primeras aplicaciones grandes, creció el peso de cambios de código (correcciones en dependencias compartidas, ifdefs por plataforma, representación de datos, etc.).
- Configuración y procesos: en la fase final, casi todo eran archivos de configuración y procesos de soporte; además, el número de commits se disparó, señal del escalado al resto del repositorio.
Un detalle relevante: la mayoría de commits relacionados con la migración fueron pequeños. Los más voluminosos se debían, sobre todo, a listas o configuraciones grandes, no a cambios intrincados en un único fichero.
La IA entra en escena: CogniPort, un agente para “arreglar” builds y tests
Para atacar el remanente —ese long tail de apps que aún no compilan o no pasan sus tests en Arm— Google ha construido CogniPort, un agente de IA generativa orientado a automatizar el resto de la migración.
Cómo funciona: CogniPort opera sobre los errores de build y de test. Si una librería, binario o test no compila o falla, el agente interviene e intenta arreglarlo sin intervención humana. Por dentro, implementa tres bucles agénticos anidados:
- Un orquestador que invoca a los otros dos agentes.
- Un build-fixer que compila un objetivo y modifica archivos hasta que construye (o se da por vencido).
- Un test-fixer que ejecuta un test y modifica archivos hasta que pasa (y, si hace falta, llama al build-fixer).
En pruebas con commits históricos (245 casos de Code & Test Adaptation revertidos a propósito), sin prompts especiales, el agente fue capaz de arreglar fallos de test en un 30 % de los casos. Sus puntos fuertes: tests, condicionales por plataforma y ajustes de representación de datos. Es un punto de partida: la compañía espera mejorar con optimizaciones adicionales.
Axion + multiarch: implicaciones para Google… y para el sector
- Elasticidad a otra escala: si el scheduler puede colocar la misma carga en x86 o Arm según disponibilidad y coste, sube la ocupación media de los clústeres y baja el coste efectivo por servicio.
- Sostenibilidad: con hasta un 60 % de mejora en eficiencia energética frente a instancias comparables, el impacto agregado en consumo y emisiones es significativo.
- Menos dependencia ISA-proveedor: diseñar aplicaciones multiarch por defecto reduce el riesgo tecnológico y abre el abanico de hardware posible (Axion hoy, otros Arm mañana), sin rehacer software.
- Cambios culturales: la migración ha mostrado que la fricción real estaba en tests, builds y pipelines. Esa capa —a menudo “invisible”— es la que conviene diseñar para la portabilidad.
¿Qué significa para clientes de Google Cloud?
Aunque el post se centra en infraestructura interna, las conclusiones sí salpican al cliente:
- Más opciones de instancia con mejor precio-rendimiento y eficiencia (Axion), sin sacrificar compatibilidad si el software está multiarch-ready.
- Mejor TCO en cargas elásticas, microservicios y data plane que aprovechen la flexibilidad de scheduler entre ISAs.
- Una guía de cómo abordar migraciones realistas en organizaciones grandes: empezar por tooling/tests, automatizar builds y rollouts, y usar IA como multiplicador, no como sustituto de ingeniería.
Qué viene ahora: “multiarch por defecto”
Google planea usar automación para atacar decenas de miles de apps pendientes y ha fijado la política de “multiarch by default” para nuevas aplicaciones. Las piezas estructurales —monorepo visible, tooling multiarch, automatismos como Rosie y CHAMP— están en su sitio. Con CogniPort tomando el relevo del “último kilómetro”, el objetivo declarado es llevar los servicios en producción hacia una neutralidad de arquitectura más estricta.
La lectura de fondo para el sector es clara: la migración de ISA ya no es ciencia ficción, es operación industrial. El foco —al menos en esta experiencia— no está en “traducir” vectores o ajustar ensamblador, sino en domesticar la periferia: tests, builds, configs, pipelines. Y ahí la IA generativa puede ser el obrero incansable que faltaba.
Preguntas frecuentes
¿Qué son los procesadores Google Axion y qué aportan frente a instancias comparables?
Axion son CPUs Arm diseñadas por Google para sus centros de datos. Según la compañía, ofrecen hasta un 65 % mejor precio-rendimiento y hasta un 60 % más de eficiencia energética que instancias comparables en Google Cloud, manteniendo compatibilidad de software cuando las aplicaciones son multiarch.
¿Cómo funciona CogniPort, el agente de IA para portabilidad de ISA?
CogniPort se activa cuando falla una compilación o un test en Arm. A través de bucles agénticos (orquestador, build-fixer y test-fixer), edita archivos de código, build scripts o configs y reintenta hasta que el objetivo compila o el test pasa. En pruebas iniciales con commits históricos, solucionó un 30 % de fallos de test sin prompting adicional.
¿Cuántas aplicaciones ha portado Google y cuáles corren ya en producción multiarch?
Google afirma haber migrado más de 30.000 aplicaciones a Arm, con servicios como YouTube, Gmail o BigQuery sirviendo tráfico en x86 y Arm a la vez. El hardware Arm está plenamente utilizado y se despliega más capacidad mes a mes.
¿Dónde estuvieron los mayores problemas de la migración multiarch?
Contra lo esperado, no en las diferencias “profundas” de ISA, sino en tests sobreajustados a x86, sistemas de build antiguos y configuraciones que no contemplaban variantes por arquitectura. La automatización —Rosie, sanitizers/fuzzers, CHAMP— y la IA han sido clave para industrializar el proceso.
Fuentes: Entrada técnica de Google Cloud (“Using AI and automation to migrate between instruction sets”) y preprint “Instruction Set Migration at Warehouse Scale”; cobertura divulgativa en El Chapuzas Informático sobre la migración a Axion/Arm y el uso de IA en el proceso.
vía: cloud.google
