Todos escuchamos la promesa: Graviton ofrece mejor precio-rendimiento. Y este año la apuesta subió: Graviton5 ya está disponible en general, con 192 núcleos por socket y la promesa de 25% más de rendimiento sobre Graviton4. Lo que casi nadie hace es medir qué significa eso para su propio workload.

Esta charla lo mide en EKS. Tres clases de workload en el mismo clúster, con node groups x86 y Graviton: una aplicación Java de alta concurrencia (donde importa que un vCPU de Graviton sea un núcleo físico y no un hermano de hyperthreading), MongoDB (que vive del ancho de banda de memoria) y un servicio Go como control. Para cada una mostramos el número y el porqué: profiling continuo con eBPF, usando la señal de Profiles de OpenTelemetry (estable desde 2025), con flame graphs que muestran adónde se va el tiempo en cada arquitectura. De yapa: la evolución generacional medida, de m5 a M9g.

La charla es deliberadamente angosta y profunda: tres workloads, tres porqués, y una regla de decisión por clase de workload para aplicar el lunes. La metodología se narra como parte de la historia (warmup del JIT, coordinated omission, vecinos ruidosos), y el harness completo es open source y queda publicado: k6, Prometheus, Pyroscope, imágenes multi-arch con buildx y Karpenter eligiendo por precio-rendimiento. Cerramos con el camino de migración real en EKS: node groups mixtos, Spot más Graviton como la configuración más eficiente, y el bloqueador del que nadie habla: los DaemonSets.