Google ha puesto cifras —y método— a algo que los equipos de sistemas llevaban tiempo contemplando: ejecutar las mismas cargas en x86 y Arm a la vez. Con sus CPUs Axion (Arm) sirviendo YouTube, Gmail o BigQuery en paralelo a x86, la compañía afirma hasta un 65 % mejor precio-rendimiento y hasta un 60 % más de eficiencia energética frente a instancias comparables dentro de Google Cloud. Más allá del titular, la experiencia de Google deja una guía útil para administradores de sistemas que operan entornos VMware/Proxmox, Kubernetes y bare-metal y que quieren preparar su software para un mundo multi-arquitectura.
“La fricción no estuvo en instrucciones o ensamblador; estuvo en tests, builds, pipelines y configuraciones que asumían x86 como única vía”, resume David Carrero, cofundador de Stackscale – Grupo Aire (cloud privado europeo sobre VMware y Proxmox). “Si fortaleces esa capa, pasar a multi-arquitectura deja de ser una epopeya y se convierte en operación industrializable”.
Nota importante: Stackscale hoy no ofrece nodos Arm. Su propuesta es cloud privado x86 (VMware y Proxmox) y acompañamiento para que el software del cliente sea multi-arquitectura a nivel de aplicación y contenedor, de modo que pueda correr en x86 ahora y esté listo para Arm cuando y donde el cliente lo decida (laboratorio propio, nubes públicas o futuras opciones del mercado).
Qué ha hecho Google (y por qué importa a un sysadmin)
- Ejecución real multiarch: 30.000+ aplicaciones internas compiladas y ejecutándose en x86 y Arm.
- Producción: clústeres mixtos donde el orquestador coloca cada job en la ISA con mejor encaje para elevar la ocupación media del clúster.
- Automatización masiva: 38.156 commits (≈700.000 líneas tocadas) con picos en tooling/tests al inicio y, después, en configuración y procesos.
- IA como multiplicador: CogniPort, un agente que reacciona a fallos de build/test y propone cambios; en una prueba con commits históricos, arregló el 30 % de fallos de test sin prompts especiales.
Traducción operativa: el reto no fue “portar código a mano”, sino domar la periferia para que los mismos artefactos (imágenes, paquetes, manifiestos) convivan por ISA sin romper despliegues, observabilidad ni SLOs.
Dónde está la fricción al pasar de x86 a Arm (y cómo atacarla)
1) Tooling, CI/CD y pipelines
- Compilación multiarch: active targets arm64 en CI (GCC/Clang) y matrices de build (
amd64/arm64). - Imágenes multiarch: publique manifiestos OCI con variantes por ISA (p. ej.,
docker buildx) y tests que verifiquen que el runtime baja la imagen correcta. - Emulación (QEMU): útil en CI para tests rápidos, no válida para rendimiento.
Carrero: “En CI/CD, arm64 debe ser primer ciudadano. Si un merge rompe Arm, falla como un lint. Es la única forma de que la deuda no crezca.”
2) Tests que asumen x86
- Determinismo: evite pruebas dependientes de timings finos o del modelo de memoria.
- Sanitizers/fuzzing: actívelos en ambas ISAs para cazar data races que x86 (TSO) oculta mejor.
- Fixtures: haga explícitas las tolerancias (coma flotante) y documente diferencias razonables por plataforma.
3) Código y librerías
- Intrinsics: aísle AVX/SSE tras abstracciones y ofrezca rutas NEON/SVE o fallbacks.
- Empaquetado y binarios: revise packing, bitfields y serialización (Arm actual es little-endian).
- Cripto/compresión: compruebe aceleraciones hardware equivalentes y coherencia de fallbacks.
4) Configuración y despliegue
- Manifiestos: parametrice por arquitectura (Kubernetes/Helm/Ansible/Terraform).
- Scheduler: etiquete nodos por ISA; defina afinidades/taints; garantice doble vía (x86/Arm) para servicios críticos.
- Canarios por ISA: rote canaries por arquitectura y mida errores/latencias separadas.
Carrero: “Muchos incidentes no fueron de CPU, sino de coreografía de config: rollouts que no entendían dos variantes, daemons para una ISA y sidecars para otra. Eso hay que diseñarlo.”
5) Observabilidad y SRE
- Etiquetas: añada arquitectura como label transversal en logs, métricas y traces.
- SLOs por ISA: latencias y errores separados; alertas que comparen x86 vs Arm.
- Evacuación automática: imite el enfoque de Google (CHAMP): si un job entra en crash-loop o baja throughput en Arm, eváquelo y márquelo para afinado offline.
Coste, energía y capacidad (lo que dicen los datos y lo que puede hacerse hoy)
Google asegura hasta 65 % en precio-rendimiento y hasta 60 % en eficiencia energética. Si opera on-prem, esos números impactan en PUE, densidad y rack planning. ¿Qué puede hacer hoy un equipo que opera solo x86?
- Planificación de mezcla lógica: aunque todo su cómputo físico sea x86, prepare su software para multi-ISA: imágenes multiarch, tests por ISA, feature flags.
- Evaluación realista: pruebe Arm en laboratorio o nube pública (cuando tenga sentido) para comparar SLOs y coste por transacción.
- Elasticidad futura: con el software multiarch, mañana podrá colocar cargas donde resulte más eficiente (x86 en Stackscale/privado, Arm donde lo decida), sin rehacer su aplicación.
Carrero: “En Stackscale hoy somos x86 (VMware/Proxmox). Aun así, recomendamos diseñar multiarch arriba: te prepara para aprovechar Arm cuando convenga (laboratorio, pública, futuro proveedor), sin encallarte en el vendor lock-in de una sola ISA.”
Seguridad y cumplimiento
- SBOM por ISA: emita inventarios de componentes específicos de arquitectura.
- Criptografía: alinee bibliotecas y certificaciones por plataforma (FIPS si aplica).
- Hardening: compare paridad de ASLR, seccomp, flags de compilación y políticas de ejecución entre ISAs.
¿Y si opero VMware/Proxmox (solo x86) en un cloud privado?
El núcleo de la migración es aplicativo. A nivel de plataforma:
- VMware/Proxmox: soporte maduro en x86; verifique roadmaps y casos de uso antes de pensar en Arm a nivel de hipervisor.
- Contenedores/Kubernetes: es la vía más neutra para preparar multiarch hoy —aunque despliegue únicamente en nodos x86— y decidir más adelante dónde ejecutar Arm.
- Interoperabilidad: orqueste por ISA con labels; publique imágenes multiarch; evite acoplarse a templates heredados.
Carrero: “Nuestra misión hoy es dar x86 robusto y predecible con VMware/Proxmox, y ayudar a clientes a que su software esté multiarch-ready. Las pruebas en Arm pueden hacerse en lab o pública; cuando el mercado ofrezca alternativas Arm privadas que encajen, el esfuerzo ya estará hecho arriba.”
Hoja de ruta pragmática (90 días, sin Arm en plataforma)
Día 0–15 — Descubrimiento y base técnica
- Inventario de servicios por criticidad y dependencias (intrinsics, binarios nativos).
- Activar builds arm64 en CI (matriz) y generar imágenes multiarch.
- Añadir arquitectura como label en observabilidad.
Día 15–45 — Piloto controlado en x86
- Elegir 3–5 servicios (CPU-bound, bajo acoplamiento).
- Desplegar solo en x86, pero con artefactos multiarch y canarios lógicos por ISA (validación en CI + entornos de staging).
- Corregir tests y config rotos; documentar runbooks.
Día 45–90 — Escalado y verificación externa
- Añadir automatismos: lint de Dockerfiles multiarch, validaciones de Helm por ISA, reglas de evacuación (simuladas).
- Si procede, realizar pruebas puntuales en laboratorio o nube pública Arm para comparar SLOs y coste/req.
- Adoptar política “multiarch by default” para servicios nuevos.
Qué no hacer
- Confundir “compila Arm” con “rinde Arm”: la validación de SLOs es imprescindible.
- Forzar emulación en producción: QEMU es para CI, no para benchmarks ni capacity planning.
- Desplegar sin feature flags: los cortes por arquitectura deben ser reversibles.
- Ignorar terceros: confirme SDKs, drivers y appliances en Arm (si piensa usarlo fuera) o alternativas.
Opinión final
“El objetivo no es ‘abandonar x86’, sino ganar opciones”, remata Carrero. “En Stackscale ofrecemos hoy x86 con VMware y Proxmox, y ayudamos a que los clientes estén preparados para multi-arquitectura a nivel de software. Cuando decidan dónde y cuándo ejecutar Arm, no tendrán que reescribir nada: será otra diana para sus pipelines”.
Preguntas frecuentes
¿Qué cargas “ganan” antes al pasar a Arm (cuando lo pruebe fuera de mi plataforma x86)?
Servicios CPU-bound con poco uso de intrinsics específicos; microservicios en Go/Java/Python; APIs stateless; workers; y componentes de datos sin dependencia de AVX. Valide siempre SLOs y coste/req.
¿Cómo publico imágenes de contenedor para x86 y Arm sin duplicar repos?
Con manifiestos multiarch (p. ej., docker buildx build --platform linux/amd64,linux/arm64 --push) y un único tag por versión; el runtime descargará la variante correcta.
¿Necesito reescribir mis apps para Arm?
En la mayoría de casos no. Debe activar builds, arreglar tests/config, y abstraer intrinsics o llamadas nativas. Donde use AVX/SSE, aporte rutas NEON/SVE o fallbacks.
Si hoy solo tengo x86 (Stackscale/privado), ¿qué gano preparando multiarch?
Gana independencia tecnológica y velocidad de decisión: podrá mover cargas a Arm en lab o pública sin rehacer software, y volver a x86 donde tenga sentido. El TCO mejora cuando la arquitectura no limita su despliegue.
