Un día nublado en Rosario

Bueno, el 4 de diciembre estaba realmente soleado, pero el tema del que fuimos a hablar con Johnny Halife a la UTN de Rosario fue Cloud Computing. Me tomó un tiempo escribir este post, pero ahí va.

Salimos de Buenos Aires a las 3:30 AM, y llegamos a Rosario cerca de las 7:30 para desayunar frente a la UTN (Universidad Tecnológica Nacional) con Andrés Joaquín, nuestro anfitrión y organizador de esta serie de reuniones sobre arquitectura de software.

Nos gustó mucho el nivel del público, profesionales realmente experimentados (más allá del título o no de “arquitecto”) provenientes de diferentes ámbitos laborales y plataformas tecnológicas (aclaro que la UTN proporciona el lugar pero la gente viene de todos lados).

Por cuestiones históricas, empezamos por Amazon Web Services, cubriendo brevemente sus servicios y mostrando un poco cómo es el proceso de provisioning de máquinas virtuales en EC2.

No voy a contar todo el contenido de más de dos horas de charla en este post, pero tal vez en otros sucesivos deje constancia de lo principal, siguiendo el modelo de madurez “don’t be a canuto”.

En general, contamos que Amazon provee un servicio de almacenamiento conocido como S3 (Simple Storage Service), otro de máquinas virtuales a demanda llamado EC2 (Elastic Compute Cloud), y para conectar las aplicaciones entre las diferentes máquinas, un servicio de colas (Simple Queue Service).

Iniciar una máquina virtual en Amazon es sencillo. Una vez que abrimos una cuenta (via tarjeta de crédito) y obtuvimos un Access Key ID, podemos acceder a un panel web donde seleccionar una imagen preconstruida (hay diversas versiones de Unix/Linux, Windows y Windows+SQL Server), indicar la cantidad de instancias y encenderlas, sin importar si es una sola o cientos, en segundos estará disponible nuestra infraestructura. El costo se calcula por hora de procesamiento, tráfico externo (no entre máquinas), o espacio de almacenamiento, pero realmente es muy económico comparado con el costo de comprar, administrar y operar hardware en nuestras propias instalaciones.

Luego de cubrir bastante los Servicios de Amazon, cambiamos a Windows Azure, la flamante estrategia de Cloud Computing de Microsoft.

Como comparación, digamos que si Amazon nos brinda algo completamente flexible (acceso prácticamente completo al ambiente virtualizado), lo que a su vez nos exige bastante conocimiento de infraestructura para lograr aplicacions escalables, Azure nos provee una abstracción mucho mayor, donde no tenemos en principio tanto control, pero en cambio el paradigma de programación permite construir aplicaciones escalables de manera sencilla y familiar para cualquier desarrollador experimentado en .NET.

En lugar de “maquinas virtuales”, Azure nos permite levantar instancias de “roles”, sobre los que desplegamos aplicaciones construidas utilizando Visual Studio.

Hay dos roles principales en ese sentido, que son los Web Roles, conteniendo aplicaciones ASP.NET (pueden ser Webforms ó MVC) ó Worker Roles, que son básicamente procesos puros.

La clave para construir aplicaciones escalables es seguir los principios fundamentales que ya deberíamos seguir: que los procesos estén bien separados de la presentación. De esta forma podemos ir aumentando la cantidad de instancias de los roles de presentación o proceso en forma independiente, para cubrir la demanda en cada momento.

Windows Azure provee además un servicio de almacenamiento de Blobs (imagenes, archivos, video, etc), uno de tablas no relacionales (el modelo estándar para escalar bien en la web con datos no excesivamente estructurados) y por supuesto, un mecanismo de colas por el que se comunican los roles.

Como un complemento a Windows Azure, Microsoft agregó SQL Azure, que es lo que la comunidad reclamó tempranamente: soporte para bases de datos relacionales; básicamente SQL Server en la nube.

Al finalizar nuestras dos sesiones, Pablo Francavilla y Juan Pablo Picasso de GetSense, describieron Google App Engine, la alternativa de Google para la nube.

Este servicio es más similar a Azure que a Amazon en el sentido en que no hay control alguno ni referencias a la infraestructura real, sino un conjunto de APIs para dos lenguajes principales: Python y Java. Hay posibilidad de ejecutar algunos otros lenguajes que corren sobre la máquina virtual de Java, como Scala o Groovy, pero no es el foco del servicio.

Algunas conclusiones que expusimos en conjunto al final de la jornada:

• Ninguno de los tres modelos es mejor. Cada uno tiene sus ventajas y limitaciones.
• Mientras que Amazon es el más cercano a la infraestructura real, Azure y App Engine pueden ser más productivos para producir aplicaciones si uno ya tiene experiencia en .NET, Java o Python.
• Es totalmente factible utilizar más de uno de estos servicios en varios contextos, y de hecho en nuestro caso, lo hacemos con frecuencia.
• Esta tecnología no está lejos de nuestra realidad. De hecho, con los costos mayores de hardware que solemos tener en América Latina al sumar transporte y derechos aduaneros, este tipo de servicio en donde se paga por lo que se usa, y facilita escalar, es una gran ayuda, sobre todo para nuevas iniciativas.