Cloud computing (I)


Cloud computing (I)

Este artículo no es un artículo al uso, más bien es un ensayo que supongo corregiré en alguna ocasión. También es una serie de reflexiones personales acerca de lo que entiendo que es el famoso y de moda Cloud Computing.

Bien, comenzamos.

Está de moda usar el término Cloud Computing indiscriminadamente. Ahora todos los proveedores de servicios se quieren apuntar al carro y ofrecen servicios “Cloud” que, bajo mi punto de vista (y seguramente el de muchos otros) son otra cosa. De hecho, otra cosa que ya existía casi desde siempre. Es como si los profesores de primaria, de repente, decidieran ir a clase a impartir “Learning”. Más de lo mismo, pero con otro nombre.

Computación en la nube no es que los servicios que contratamos están en un centro de datos muy grande y muy seguro, porque eso es lo que es cualquier servicio de hosting que se precie.

Computación en la nube no es que contratemos online un servicio de aplicación en un proveedor y nos emita automáticamente facturas por los servicios consumidos. Al menos no sólo eso.

Computación en la nube no es que contratemos un espacio en un proveedor en el que ubiquemos nuestra máquina (o granja) y nuestros servicios tengan un ancho de banda muy “ancho” pero nosotros seamos los que controlemos la máquina (o granja).

Bajo mi punto de vista, la computación en la nube, tiene implícitas unas cuantas características inevitables, que voy a detallar en los siguientes puntos.

Escalabilidad lineal de costes

El primer punto importante para considerar el servicio “cloud”, es la escalabilidad de costes lineal.

¿Qué es? Pues muy sencillo. Si consideramos una gráfica de dos dimensiones en la que tenemos en la X los recursos utilizados y en la Y el coste del servicio, la línea debe ser absolutamente recta y, coincide exactamente, con los recursos contratados:

Gráfico de escalabilidad lineal

En un servicio de hosting tradicional, no podemos contratar los recursos en el momento en que los necesitamos, por lo que para dimensionar adecuadamente los requerimientos de nuestro servicio, tenemos que hacerlo con cierta dosis de generación de hipótesis basada en conocimientos previos de uso. Esta hipótesis nos suele llevar a errores en ciertas ventanas de tiempo, es decir, hay momentos del tiempo en que tenemos más recursos contratados de los que usamos (sobredimensionamiento) y hay momentos del tiempo en que tenemos menos recursos contratados de los que necesitamos (cuellos de botella):

Esto es debido principalmente al modo de licenciamiento de los proveedores de hosting. Es difícil encontrar uno que nos permita contratar 3 máquinas por 2 horas, las siguientes 5 horas contratar únicamente 1 máquina, después 10 horas con 8 máquinas, y así sucesivamente. Lo más normal que nos podemos encontrar es que el tiempo mínimo por recurso que podamos contratar sea de 1 mes (lo más habitual será de 3 meses en adelante).

Si en lugar de un hosting tenemos contratado un housing, no hay comparación posible. O tenemos el servicio sobredimensionado, o tenemos un gran cuello de botella. Nuestro dimensionamiento no puede ser evolutivo, es decir, a veces más o a veces menos. Tenemos las máquinas (o front-ends) que tenemos: ni más, ni menos. Y estaremos de acuerdo en que no tenemos una carga lineal de trabajo en una aplicación. Es decir, seguro que, sea una página web, un ERP, un CRM, o cualquier otra aplicación, no tendremos que soportar el mismo número de peticiones por hora durante las veinticuatro horas del día.

Imaginemos que somos Facebook. Ambicioso, ya lo sé. Pero imaginémoslo por un momento. Seguramente, la carga de peticiones que debe tener en Europa durante las horas GTM -4 y GTM +2 de 10:00AM a 22:00PM debe ser sensiblemente superior a entre las 22:00PM y las 10:00AM. Y, en el mismo rango de horas, la carga de peticiones seguramente se balanceará hacia las américas subiendo el índice de GTM o hacia Asia bajando el índice de GTM. Si tenemos, pongamos por caso, un par de centros de datos en Europa, otro par en América y otro par en Asia, en cada centro de datos contratamos, por redondear, 12 horas diarias con 100 máquinas y 12 horas diarias con 10 máquinas.

La diferencia de coste es evidente si la comparamos con tener 24 horas al día 100 máquinas en cada centro de datos. Si conseguimos balancear el número de máquinas contratadas hacia los centros de datos de América y Asia según la hora del día, seguramente, con casi la mitad de coste, tendremos cubiertos todos los picos posibles de servicio solicitado que si tuviéramos sobredimensionado el servicio a 100 máquinas por centro de datos.

Hagamos el ejercicio en una tabla simplificando a un coste de 25 céntimos por front-end/hora:

Coste porFront-End/hora 0,25 €
Centro de datos cloud
Europa América Asia
Horas 12 12 12 12 12 12
Front-Endscontratados 100 10 100 10 100 10
Coste mensual (30 días) 9.000 € 900 € 9.000 € 900 € 9.000 € 900 €
Total 9.900€ Total 9.900 Total 9.900€

Total:

29.700 €
Centro de datos standard
Europa América Asia
Horas 24 0 24 0 24 0
Front-Endscontratados 100 0 100 0 100 0
Coste mensual (30 días) 18.000 € 0 € 18.000 € 0 € 18.000 € 0 €
Total 18.000€ Total 18.000€ Total 18.000€
Total: 54.000 €

Y eso que nuestro dimensionamiento simulado sólo ha contemplado dos situaciones, 100 y 10 front-ends. El ahorro sería más importante si consideráramos un dimensionamiento progresivo tanto en subida como en bajada.

Continuará…

Google
Visita mi perfil en Google Plus

Anuncios

Un comentario en “Cloud computing (I)

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s