Durante años, optimizar el rendimiento en la nube fue para mí una sucesión de decisiones sueltas: elijo una VM con más CPU, le sumo un disco más rápido, le activo accelerated networking. Cada palanca por su lado, como si fueran problemas independientes. Un artículo reciente del blog de Azure propone cambiar ese marco mental y pensar el rendimiento a nivel sistema, no por instancia. Es una de esas distinciones que parecen obvias una vez dichas, pero que en la práctica cambian bastante cómo uno diseña —y cuánto termina pagando—.
El rendimiento no es una sola decisión
La idea central es simple: ya sea que entrenes un modelo de IA, escales una plataforma de Kubernetes o corras una base de datos crítica, el rendimiento ya no es una decisión única sobre CPU, almacenamiento o red. Es el resultado de cómo los tres trabajan juntos.
Y acá viene el matiz que me parece más importante: los cuellos de botella se mueven. Una base de datos puede estar limitada por la latencia del disco en un momento y, minutos después, por el ancho de banda de red. Un pipeline de IA puede frenarse no por falta de cómputo —que es lo primero que uno mira—, sino porque los datos no se mueven lo suficientemente rápido entre nodos. Si optimizás una pieza mirándola en soledad, muchas veces lo único que lográs es correr el cuello de botella de lugar, no eliminarlo. Lo viví más de una vez: subís la VM, la base «sigue lenta», y resulta que el problema nunca fue la CPU.
Qué significa «a nivel sistema» en Azure
El enfoque de Azure IaaS, según el artículo, es alinear compute, storage y networking a las necesidades de cada carga de trabajo y entregar rendimiento como un sistema coordinado, no como un rejunte de componentes sueltos. Suena a frase de marketing, pero el ejemplo concreto que dan lo aterriza bien: Azure Boost.
Azure Boost descarga el procesamiento de almacenamiento y red desde la CPU del host hacia hardware y software dedicados. En criollo: en vez de gastar ciclos del procesador moviendo paquetes de red y bloques de disco, esa tarea la hace un componente aparte. ¿El efecto? Menos overhead del hipervisor y más CPU libre para lo que de verdad importa —en una carga de IA, eso es entrenamiento e inferencia—.
Es un buen ejemplo del principio completo. No es que la VM «tenga más CPU»; es que el sistema entero está diseñado para que la CPU no se desperdicie en plomería. Y lo mismo aplica a otras piezas que ya conocemos del catálogo: el accelerated networking que saca el procesamiento de red del camino, los discos premium y ultra para cuando el límite real es de I/O, o ubicar las VMs cerca entre sí para bajar la latencia interna. Ninguna de esas decisiones rinde sola: rinden cuando están elegidas en función de dónde está el límite de esa carga puntual.
El error clásico: subir el SKU y rezar
Esto conecta con algo que veo seguido en proyectos de la región, y que tiene que ver con cómo manejamos los presupuestos acá. Cuando algo «va lento», el reflejo casi siempre es el mismo: subir el SKU de la VM. Es la opción más rápida de aplicar y la más fácil de justificar en una reunión. El problema es que muchas veces es cara e inútil al mismo tiempo: pagás el doble por una instancia más grande y el cuello seguía estando en el almacenamiento, en la red o en cómo está escrita la query.
En contextos de presupuesto ajustado —que en LATAM es la norma, no la excepción— ese reflejo se paga doble. Escalar a ciegas quema plata que no sobra. Pensar el sistema completo, en cambio, suele dar más rendimiento por peso invertido, porque atacás el límite real en lugar del primero que se te ocurrió.
Cómo lo encararía
Desde mi punto de vista, el cambio práctico es de método más que de tecnología. Antes de tocar el tamaño de nada, medir dónde está realmente el límite en cada momento: ¿es CPU, es latencia de disco, es ancho de banda, es la aplicación? Las métricas de la propia plataforma alcanzan para tener una primera respuesta honesta, y casi nunca confirman la corazonada inicial.
Después sí, elegir la palanca correcta para ese cuello puntual: a veces es un disco con más IOPS, a veces es accelerated networking, a veces es Azure Boost para liberar CPU, y a veces —seamos honestos— no es infraestructura, es el código. Lo importante es que la decisión salga de la medición y no del reflejo. Y volver a medir después, porque al destrabar un cuello aparece el siguiente. Es iterativo, no es un seteo de una vez.
El límite casi nunca está donde uno cree
El artículo es parte de una serie de Azure IaaS que cubre buenas prácticas de rendimiento, resiliencia, seguridad, escalabilidad y costo, y vale leerla entera con esta lente. Pero si me quedo con una sola idea es esta: antes de cambiar la pieza que se ve lenta, mirá el sistema completo. En cargas de IA, cloud-native o bases de datos críticas, el límite casi nunca está donde uno cree que está. Pensar a nivel sistema no es una sutileza de arquitecto: es lo que separa gastar bien de gastar de más.
Fuente
- Microsoft Azure Blog — Azure IaaS: Deploy high-performance workloads with a system-level approach (mayo de 2026).
