Economía en la nube -- lo que tenés que saber
Hola a todos! Hoy quiero compartirles lo que creo yo es uno de los puntos más importantes por los cuales tantos desarrolladores y empresas está optando por la nube: economía.
Esencialmente, hay tres maneras de reducir costos a través del cloud:
- Delegar la administración de IT en terceros.
- Optimización del uso de recursos.
- Economía de escala.
Delegar la administración de IT en terceros
Si tuviéramos que montar todo nuestro centro de datos, servidores, array de servidores o lo que fuera, eso trae consigo algunos temas a tener en cuenta. Por ejemplo:
- Comprar equipos (gastos upfront, o "comprar todo de una").
- Cableado
- Networking
- Refrigeración
- Comprar licencias (de ser necesario).
- Control de acceso/seguridad
- Cuidado del espacio físico
- Planes de contingencia
- Administración de sistema operativo/software/etc.
- Otros (que pueden ser muchos)
En cambio, si delegamos esta responsabilidad en un tercero, todo esto estará a cargo de ellos. Nosotros simplemente accedemos remotamente a un ambiente en donde tenemos control desde el Sistema Operativo (Infraestrucutra) para arriba (IaaS), o desde la Plataforma para arriba (PaaS), o desde la aplicación (Software) para arriba (SaaS). Por supuesto que nuestra administración no será "nula", pero definitivamente no tendremos que ocuparnos de todo lo mencionado arriba ni tampoco enfrentar costos upfront.
Optimización del uso de recursos
Este apartado es fundamental, y es el principal motivo por el cual la nube es más económica; sin embargo, no todos lo tienen en claro.
Recordemos que la nube se puede utilizar de forma elástica, es decir, le pido tantos recursos como necesito. Si necesito 1 servidor, la nube podrá aprovisionarlo, si necesito 100, los aprovisionará, si necesito 1000, lo mismo. De igual manera funciona para otros servicios, por ejemplo, si necesito 1 MB o 100 TB de storage, mismo concepto.
Teniendo en cuenta lo anterior combinado con la caracterísitca de pago por uso, acá seguro empezás a ver las ventajas. Si aún no lo viste, pongamos un ejemplo práctico.
Caso de estudio
Supongamos que soy el dueño de un restaurant y tengo una aplicación web para recibir pedidos online. Seguramente, la curva de tráfico será como la siguiente:
Un pico al mediodía, un pico más grande a la noche (cuando la gente hace más pedidos), y luego más tranquilo el resto del día.
Teniendo este escenario, si tuvieramos que comprar, alquilar o reservar servidores, deberíamos tener al menos tantos servidores como el mayor de los picos. Opcionalmente (y recomendado!), dejaré un 10 o 15% de holgura por si ese pico creciera.
Esto pareciera funcionar bien, sin embargo acá aparecen dos problemas:
- ¿qué pasa si el mayor pico crece?
- ¿qué pasa con los recursos ociosos? (Por ejemplo, a las 5 pm, mis servidores estarán al 5% cuando "pagué" para tener la capacidad de las 9 pm) .
Los dos problemas mencionados son críticos. En el primer caso, la nube y su aprovisionamiento elástico permitirá utilizar más servidores en caso que fuera necesario. Para el segundo caso, podemos inversamente apagar servidores y ahorrar dinero, evitando recursos ociosos.
De manera más gráfica, una aplicación en la nube bien configurada debería comportarse de esta forma:
Como se puede ver, la curva azul representa a los servidores mientras que la violeta la demanda real. Cuanto más se asemejen estas dos curvas, menos dinero estaremos pagando al final del período ya que usamos únicamente lo que necesitamos.
Ahora comparemos las dos curvas:
Si nosotros pagamos por uso únicamente, entonces los costos estarán representados por el área debajo de cada una de las curvas (azul y roja), osea la integral de cada función. Como se puede ver, en el caso de la nube, lo máximo que podemos llegar a pagar es igual a lo mínimo que costarán los servidores dedicados (asumiendo el mismo costo por hora, lo cual no es cierto, hablo de esto más adelante).
En el primer caso, los costos al final del día serán 5 servidores * 24 horas.
En el segundo caso, (1 servidor/hora) + (1 servidor/hora) + ... + (3 servidores/hora) + ... + (5 servidores/hora) + ... + (1 servidor/hora) = 2.5 (en promedio) servidores/hora.
Al final del mes, esto será mucho más económico.
Seguro te preguntarás, ok perfecto, y entonces tengo que estar constantemente prendiendo y apagando?
La respuesta corta es sí, pero tené en cuenta que podes automatizarlo o dejar que Azure lo haga por vos. Existen servicios como Azure Automation que permiten prender y apagar recursos en base a tu necesidad. Al mismo tiempo, para todo lo que es PaaS, podés utilizar las reglas del Network Load Balancer o balanceador de cargas de red para configurar políticas de auto-scale. Con estas reglas, las instancias pueden aprovisionarse y desaprovisionarse de forma automática (!). Para más info, visitá este link.
Un ejemplo podés verlo en este post, donde configuro el auto-scale en base a una cola de mensajeria.
Otro buen ejemplo, es la configuración de escala automática de Websites en base al porcentaje de CPU de las máquinas virtuales:
Si el % de CPU en promedio es mayor a 80%, se encenderán más instancias, pero no más de 5. Si el porcentaje de CPU en promedio es menor al 60%, se apagarán instancias, pero no menos de 1. Para configurar distintas políticas, como Data In, Data Out, RAM u otros, lo podés hacer desde https://portal.azure.com
Economía de escala
Por último y no menor, este tema es importante también. Es lo mismo comprar 1 kg de bananas que 2 toneladas de bananas? No, seguramente el precio por unidad será mucho menor. Esto es lo mismo. Al estar nosotros hosteando nuestras apps en data-centers de volúmenes monstruosos, los costos empiezan a decrementarse. Esto es conocido como economía de escala.
Espero que sirva. Para más info, te dejo estos links: