Article De on-premise a Azure, con la mentalidad cloud correcta
La nube es cara. Eso es lo que piensan la mayoría de los proveedores de servicios cuando consideran migrar su infraestructura y servicios a Azure o la nube en general. Nueve de cada diez se arrugan por los altos costes cuando comparan su entorno on-prem con la misma infraestructura en Azure. Lo que ven es que sus costes se duplican o incluso triplican.
¿Están equivocados? No, el cálculo es correcto. Pero si compara una VM on-prem de 16 núcleos con una VM de 16 núcleos en Azure, en realidad está comparando dos cosas diferentes: peras con manzanas. Para realizar una comparación adecuada y una decisión bien fundada, debe adoptar la mentalidad cloud adecuada.
Tres pilares del concepto cloud
Para adoptar la mentalidad cloud adecuada, es necesario comprender tres pilares importantes de la nube y el equilibrio entre ellos:
1) Pago por uso frente a pago por todo
Todos los usuarios finales tienen diferentes requisitos para la capacidad de TI. Entonces, ¿qué sucede en el escenario clásico on-premise? Los proveedores de servicios proporcionan muchos recursos a sus clientes. ¿Y por qué no? Ya han invertido en todo el hardware, el centro de datos, pagan las facturas mensuales de electricidad, refrigeración, etc. Cuando apagan una máquina virtual de vez en cuando, no hay ninguna diferencia en los costes. Eso es completamente diferente en Azure.
En Azure, no paga por lo que tiene, sino por lo que realmente usa, sin todos los gastos generales adicionales.
2) Dimensionamiento correcto frente a sobreaprovisionamiento
En la mayoría de los casos, los recursos se aprovisionan en exceso en el centro de datos on-premise para garantizar que los clientes no encuentren restricciones en caso de uso imprevisto. Pero también porque los proveedores de servicios comprometen demasiado las CPU, colocando varios núcleos virtuales en uno solo físico.
Debido a esto, el uso promedio de CPU en el centro de datos local parece ser del 15 al 20%. Incluso hablé con clientes con solo un 5% (!) de uso. Puede sonar abrumador, pero la mejor práctica en Azure es usar hasta un 80%, porque las máquinas virtuales más pequeñas (y por lo tanto más baratas) se pueden aprovisionar con la última tecnología (y por lo tanto más poderosa) que en el entorno on-prem. En el caso de picos o actividades imprevistas, solo se necesitan unos minutos para crear nuevas VM para equilibrar la carga, ya sea durante cinco minutos, cinco semanas o cinco meses. ¿Se acabó el pico? Luego, el tamaño de la máquina virtual se reduce nuevamente a la máquina virtual más pequeña original.
En Azure, las máquinas virtuales más pequeñas cubren la misma carga de trabajo: 4 núcleos pueden hacer el mismo trabajo que 16 núcleos.
3) Autoapagado versus siempre encendido
El tercer pilar es lo que yo llamo "el efecto ducha". Al igual que apaga la ducha en casa cuando termina, aunque espera que su hijo se duche por la tarde, puede apagar o encender el uso de la CPU con automatización y scripts, según la demanda. Si una máquina virtual se puede apagar durante tres horas al día, digamos de 1 AM a 4 AM, se trata de un ahorro de costes inmediato del 10%. Si una empresa promedio trabaja cinco días a la semana, doce horas al día, esto significa que se puede ahorrar un 65%. Si bien esto parece mágico con una mentalidad on-prem, es todo lo contrario: es una lógica cloud sencilla con el uso de automatización y scripts.
En Azure, puede optimizar el uso de la CPU y ahorrar costes con automatización y scripts, según la demanda.
A continuación se muestra un ejemplo de los ahorros de costes que se pueden lograr cuando se equilibra el uso de la CPU con los dos pilares de dimensionamiento correcto y autoapagado.
Si los proveedores de servicios cloud realmente quieren aprovechar los beneficios de la nube, incluida la rentabilidad, deben cambiar su forma de pensar. Un caso reciente de un cliente describe lo que marca la diferencia.
Uno de nuestros partners que ya estaba usando máquinas virtuales de otro proveedor para migrar a Azure. Cuando calcularon su número de VM y núcleos para un escenario uno a uno en Azure, sus costes mensuales se duplicarían de 5.000 euros por mes a alrededor de 10.000 euros. Absolutamente prohibido.
Al analizar su uso promedio de CPU, vi que la gran mayoría de los clientes no tenían uso las 24 horas, los 7 días de la semana. Esto cambió por completo el cálculo, porque con los scripts y la automatización, las máquinas virtuales se podían encender y apagar bajo demanda.
Los costes mensuales bajaron casi un 90%: de 5.000 a 700 euros.
Aunque la aplicación aún no estaba lista para la nube, el partner decidió cambiar la aplicación, a pesar de los costes adicionales, y migrar a Azure con un ROI de 3-4 meses para reconstruir la aplicación y reducir continuamente los costes mensuales después de la transición. Todo logrado al cambiar a la mentalidad cloud adecuada.
