Cloud · 2026-10-13 · 5 min

Migrar de EKS a GKE con un agente, Spark que derrocha y PyTorch 2.15 a prueba

Esta semana: el agente de Google para migrar de EKS a GKE, el 31 % de ahorro en Spark que cuenta Salesforce y la candidata de PyTorch 2.15. Mi lectura práctica.

Esta semana me quedo con tres noticias poco vistosas y muy de oficio: una herramienta para cambiar de nube, un estudio sobre recursos que se pagan y no se usan, y una versión de prueba de la librería con la que entreno redes. Ninguna va a abrir un telediario. Las tres tocan cosas que hago a diario: decidir dónde corre algo, cuánto cuesta y cuándo actualizo.

Google lanza un agente para sacar cargas de Kubernetes de AWS

CloudTech News publicó el 7 de octubre de 2026 que Google anunció dos días antes Google Cloud Modernize, un paquete que agrupa servicios de migración que ya tenía con herramientas nuevas apoyadas en IA. La pieza más llamativa es un agente, en vista previa pública, que ayuda a mover cargas de Amazon EKS a GKE: traduce los roles de IAM de AWS a Workload Identity, pasa el ingress de ALB a la Gateway API, convierte la configuración de Karpenter y genera módulos de Terraform. Según el artículo, no aplica nada sobre un clúster en marcha, sino que abre pull requests que pasan por la revisión y la integración continua de siempre. Tampoco mueve los datos de las aplicaciones con estado: genera guías que remiten a otros servicios. Las pruebas, las decisiones de arquitectura y el corte final a producción quedan fuera, según los analistas que cita el medio, y no se dan precios.

Mi opinión: Me interesa más el diseño que el anuncio. Un agente que propone cambios por pull request y no toca producción es justo como trabajo yo con los agentes que programan: ellos redactan y yo reviso y apruebo. Dicho esto, la herramienta resuelve la parte mecánica, que es la que menos miedo da. Lo caro de una migración son los datos, las pruebas y el día del corte, y eso sigue siendo trabajo de personas. Tampoco se me escapa que es una herramienta de un proveedor para llevarte a su casa, sin viaje de vuelta. No la he probado. La lección que saco es la de siempre: cuanto más estándar sea lo que despliego, con Docker, Terraform y la Gateway API, menos necesito que nadie me ayude a mudarme.

Salesforce mide cuánto Spark paga sin usar

El blog de ingeniería de Salesforce publicó el 8 de octubre un artículo sobre cómo su equipo de Data 360 buscó recursos desperdiciados en unos ocho millones de ejecuciones de Spark al día. Cuentan que una carga pedía 40 ejecutores al arrancar y la mayoría no tenía trabajo útil al principio, y que en otro grupo de cargas el tiempo ocioso de los ejecutores superaba el 90 %. Bajaron los ejecutores iniciales a 4 en el primer caso, manteniendo la asignación dinámica, y recortaron el máximo en torno a un 20 % en el segundo. Para medir, ampliaron el plugin abierto DataFlint y lo inyectaron al enviar cada trabajo, sin tocar el código de las aplicaciones, con la telemetría viajando por Kafka hasta un lakehouse en Iceberg. Dicen que el coste semanal de cómputo de las cargas afectadas bajó un 31 % comparando cuatro semanas antes y cuatro después. Son cifras de la propia empresa y ellos mismos avisan de que es una comparación de antes y después, no un experimento controlado, y de que los ajustes solo valen para esas cargas.

Mi opinión: Me gusta porque hacen lo que yo pido siempre: medir antes de tocar. La frase que me llevo es que un trabajo que termina bien demuestra que la configuración funciona, no que sea eficiente. El 31 % no lo doy por bueno fuera de su contexto, y agradezco que lo digan ellos mismos. El método sí se puede trasladar a cualquier tamaño: ordenar las cargas por coste, mirar el tiempo ocioso, cambiar una sola cosa y observar un mes entero los tiempos, los reintentos y los fallos. En una pyme no hay ocho millones de trabajos, pero sí hay máquinas y contenedores dimensionados a ojo el primer día que nadie volvió a revisar. También me parece buena idea recoger la telemetría en la puerta de entrada y que, si la instrumentación falla, el trabajo siga adelante.

PyTorch 2.15 ya tiene candidata y fecha de salida

El 8 de octubre de 2026 el equipo de versiones de PyTorch anunció en su foro de desarrollo la primera candidata de PyTorch 2.15.0, junto con torchvision 0.29.2 y torchaudio 2.11.1. Los binarios están en el canal de pruebas, con compilaciones para CPU, CUDA 13.2 y 13.4, ROCm y XPU, además de LibTorch. El calendario que acompaña al anuncio sitúa la candidata final en la semana del 19 de octubre y la versión definitiva el 28 de octubre. El mensaje pide a la comunidad que pruebe las compilaciones y que proponga correcciones a través del seguimiento de la versión en GitHub. El anuncio no detalla las novedades ni las versiones de Python compatibles, así que de eso no puedo decir nada todavía.

Mi opinión: Esto es un aviso con dos semanas de margen, y así lo trato. No voy a poner una candidata en nada que esté en producción, pero sí tiene sentido levantar un contenedor aparte, instalarla desde el canal de pruebas y pasarle mis entrenamientos y mi inferencia de siempre. Lo que miro primero es la combinación de CUDA y controlador, porque es donde las actualizaciones me han dado más guerra y aquí las compilaciones van sobre CUDA 13. Si algo se rompe, prefiero saberlo ahora, y de paso avisar al proyecto, que descubrirlo el día que una imagen se reconstruye sola. Por eso fijo siempre las versiones en mis imágenes de Docker y actualizo cuando yo lo decido. Sobre rendimiento o funciones nuevas no opino hasta leer las notas y medir.

Lo que me llevo

• Desplegar con piezas estándar (Docker, Terraform, Gateway API) es lo que de verdad abarata cambiar de nube, con o sin agente.
• Un agente de migración que trabaja por pull request me parece el diseño correcto, pero los datos, las pruebas y el corte siguen siendo cosa mía.
• Revisar los recursos que pido de inicio en cada trabajo y contenedor: que termine bien no significa que esté bien dimensionado.
• Cambiar un parámetro cada vez y observar varias semanas antes de dar un ahorro por bueno.
• Probar la candidata de PyTorch 2.15 en un contenedor aislado antes del 28 de octubre y mantener las versiones fijadas en producción.