Os voy a contar una historia de terror. El terror de cualquier administrador de sistemas, el terror de todo financiero, y el de un humilde profesor que tuvo que pagar más de 500€ en un mes.

Una de las cosas positivas de dar formación y trastear desde los últimos 12 años con Azure, es que soy capaz de montar infraestructuras a clientes para poder realizar prácticas que los laboratorios asociados a Microsoft no tienen configurado.

Así, me pidieron montar unos equipos con SharePoint Subscription Edition. Y eso implica un maquinón:

• • 8 núcleos
• Al menos 32Gb. RAM
• 4 discos duros
• Metido en dominio
• Una SQL Developer
• El propio SharePointSE

Como me lo pidieron en el último momento posible, tiré de plantilla de Azure y implementé 1 máquina en pocos minutos para hacer todas las instalaciones y luego convertirla en una imagen de Galería para implementar lo más fácilmente posible las otras cinco.

El formador contento, yo contento por el ingreso extra, y los alumnos contentos de poder "trastear" sobre el SharePoint real.

Todo se empezó a torcer cuando me fui de fin de semana, con las máquinas convenientemente apagadas, y me encontré el lunes de que mi saldo (130€) de la cuenta, había desaparecido y la suscripción de Azure estaba bloqueada.

Empecé el lunes con llamadas de urgencia, y activando el pago por uso, liberando el tope de gasto antes de encontrar el motivo del coste inesperado

Aborde los pasos estándar revisando el tamaño de las máquinas, pero no encontraba en dónde estaban los costes. Hasta que tire del Análisis de costes por recurso que te ofrece las métricas de Azure.

Los discos duros eran los que me estaban sangrando la vida a más de 21€ al día por máquina virtual

La plantilla, por defecto (que listos estos de Azure), para una base de datos, te pone un disco para el sistema operativo, un disco para datos, un disco para temp, y un disco D efímero. Y eso es correcto para un entorno productivo que esté bajo presión real, y necesites disponibilidad y rendimiento alto. Lo cual, en un caso de formación, era MUY exagerado.

El sobrecoste fue explicándose cuando me di cuenta que, por defecto, cada disco duro tenía un tamaño de 1 Tb. Si, cada disco era ENORME. De hecho lo medí, y ninguno llegaba, ni tan siquiera, al 1 Gb. de consumo real. Y, por si fuera poco, por defecto los monta con un nivel de SSD Premium.

¿Resultado? cada disco duro superaba los 141€ al mes. Más de 3,5€ al día... cada uno... 4 por máquina... 6 máquinas... 4 días y contando.

Como siguiera a este ritmo, ya no solo me había fundido todos los beneficios posibles, sino que iba a poner (como tuve que hacer) cientos de euros.

Solución

Este es un ejemplo perfecto de la importancia crítica de FinOps.

Obviamente no podía dejar al curso sin su infraestructura de prácticas, perdería el cliente y tendría un severo daño reputacional. Pero tampoco podría soportar este coste ni por un solo día más.

Así qué analicé las métricas de CPU, RAM, y uso de almacenamiento, y decidí volver a crear la infraestructura para cada máquina virtual dejando el mismo tamaño (32Gb, 8 núcleos y 4 discos duros), pero reduciendo el tamaño del disco duro del Sistema Operativo a 128GB, y los tres discos de datos a 32Gb. Y los cuatro los configuré a nivel Standard HDD.

Así pasé de pagar 121€ por cada disco duro al mes, a menos de 1,4€. Y consiguiendo un ahorro de coste de almacenamiento y de la infraestructura de dos órdenes de magnitud (casi tres).

Para dejarlo más claro... si no hubiera corregido la configuración la previsión de costes era de 2.900€. Si lo hubiera hecho bien desde el principio no llegaría a los 35€.

Y por no hacerlo bien, palmé más de 350€.

Otra lección aprendida con sangre para siempre es: instrumentaliza un buen sistema de alertas que te avisen de este tipo de picos inesperados.

Que un fin de semana no te cueste cientos o miles de euros.