En pocas palabras
Ejecutar cargas en procesadores de arquitectura Arm, como AWS Graviton, para mejorar la relación entre rendimiento, costo y consumo energético.
Qué problema resuelve
Costos elevados de cómputo en cargas que pueden aprovechar esta arquitectura.
Cuándo utilizarlo
Microservicios, servicios web y procesamiento de datos con dependencias compatibles. Ejemplo: construir imágenes de contenedor para arm64 y amd64, y comparar el costo por solicitud bajo la misma carga.
De la idea a la práctica
Funcionamiento, ejemplos y decisiones para pasar al siguiente nivel.
Cómo funciona
Arm y x86 son arquitecturas distintas. El código interpretado o con runtime portable puede requerir pocos cambios; bibliotecas nativas e imágenes deben disponer de binarios para la arquitectura destino.
Ejemplo: comparar dos despliegues
Construye imágenes para linux/amd64 y linux/arm64 usando una imagen base y dependencias compatibles. Ejecuta el mismo conjunto de pruebas y una carga representativa en ambos entornos.
Compara latencia, throughput, memoria y costo por operación satisfactoria. También mide el tiempo de construcción y revisa agentes de monitorización y librerías nativas.
Oferta por proveedor
| Proveedor | Procesadores Arm | Dónde se usan |
|---|---|---|
| AWS | Graviton (varias generaciones) | EC2, Lambda, Fargate, RDS, ElastiCache, EKS |
| Google Cloud | Axion, Ampere Altra | Compute Engine (C4A, T2A), GKE, Dataproc |
| Azure | Cobalt, Ampere Altra | Máquinas virtuales, AKS |
Los proveedores anuncian mejoras de precio-rendimiento y de eficiencia energética frente a x86 equivalentes; la ganancia real depende mucho de la carga y debe medirse.
Compatibilidad por tecnología
| Tecnología | Situación habitual |
|---|---|
| Java / JVM | Muy buena con JDK modernos (17+); vigilar librerías con código nativo (JNI) |
| Go, Rust | Compilación cruzada sencilla (GOARCH=arm64) |
| Node.js | Buena; módulos nativos (node-gyp) deben tener binarios para arm64 |
| Python | Buena si las dependencias publican wheels aarch64; si no, compilan desde fuente |
| .NET | Buena desde .NET 6 |
| Imágenes base | Las oficiales (Debian, Alpine, Distroless, Temurin) son multiarquitectura |
| Agentes de terceros | Seguridad, APM y backups: comprobar soporte arm64 |
Imágenes multiarquitectura
docker buildx create --use
docker buildx build --platform linux/amd64,linux/arm64 \
-t us-east1-docker.pkg.dev/krediya/apps/api:1.9.0 --push .
docker buildx imagetools inspect us-east1-docker.pkg.dev/krediya/apps/api:1.9.0El registro guarda un manifest list y cada nodo descarga la variante de su arquitectura. Compilar mediante emulación QEMU es lento: usa runners nativos arm64 en CI cuando estén disponibles.
Plan de migración
- Inventario: imágenes base, dependencias nativas, agentes instalados.
- Build multiarquitectura en CI para todos los servicios, aunque se siga ejecutando en x86.
- Piloto con un servicio sin estado: un nodo pool arm64 en Kubernetes con taints o un grupo de instancias aparte.
- Medir con la misma carga (k6): p95, throughput, CPU y coste por petición.
- Ampliar progresivamente y mantener la capacidad de volver a x86.
Servicios gestionados
La forma más sencilla de empezar suele ser en servicios gestionados donde el cambio es un parámetro: bases de datos, cachés o funciones serverless con opción Arm. No todos los servicios serverless ofrecen Arm; confirma la disponibilidad en el servicio y la región concretos.
Criterios de implementación
Confirma disponibilidad en la región y compatibilidad del software. La emulación puede facilitar construcciones, pero no sustituye una medición sobre hardware real. Conserva una ruta de despliegue anterior durante la migración.
Continúa en las fuentes
Documentación oficial para verificar detalles y explorar más.