Una de las grandes ventajas de utilizar Windows Azure® es que brinda la posibilidad de escalar rápidamente las aplicaciones que corren en la nube en respuesta a cambios en la demanda.

Cuando se despliega una aplicación en Windows Azure, típicamente se definen diferentes roles. Varias instancias de cada rol pueden estar corriendo al mismo tiempo. Para simplificar las cosas, se puede pensar que una instancia de un rol, es una máquina virtual que corre dicho rol o proceso.

Windows Azure permite 2 tipos básicos para escalar la capacidad de cómputo de una aplicación:

  • Escalar hacia arriba o verticalmente (Scale Up): Incrementar el tamaño de la instancia de un rol, de manera que una misma instancia tenga más poder de cómputo.
  • Escalar hacia afuera u horizontalmente (Scale Out): Agregar más instancias de un mismo rol.

Cada una de las opciones tiene ventajas y desventajas al compararlas entre sí.

 

Límites de la escalabilidad

Para escalar hacia arriba simplemente se mejora el hardware en el que corre la aplicación. Lamentablemente, existe un límite en la capacidad física del hardware, por lo que no se puede escalar hacia arriba indefinidamente, y suele ser la razón principal por la que se decide escalar horizontalmente. Windows Azure provee opciones en la que se especifica la cantidad de núcleos de CPU y memoria RAM que se quieren utilizar en las máquinas virtuales para correr las instancias.

Por otro lado, si se escala hacia afuera, se pueden agregar una cantidad inmensa de instancias. No solo eso, sino que también se pueden distribuir geográficamente de manera que la aplicación corra más cerca de los puntos desde donde será accedida, disminuyendo así también la latencia por proximidad.

 

Costo de desarrollo

Escalar hacia arriba es muy sencillo en cuanto al desarrollo de la aplicación, ya que la misma no requiere cambios de código para mejorar el hardware en el que corre.

Escalar hacia afuera, por otro lado, implica que la aplicación debe estar preparada para así hacerlo. Por nombrar un ejemplo, en el caso de una aplicación web las instancias no deben manejar estado de sesión por sí mismas, ya que múltiples accesos de un mismo usuario podrían ser procesados por diferentes instancias de la granja de servidores. En el caso de Worker Roles, es necesario que la aplicación esté preparada para distribuir el trabajo entre las instancias que están corriendo.
Hay varias prácticas a tener en cuenta para desarrollar aplicaciones que sean aptas para granja de servidores, pero que si se las considera desde un comienzo, son mucho más fáciles de implementar que si se intenta actualizar una aplicación existente para hacerla escalar horizontalmente. Sin embargo Windows Azure® también propone soluciones a los desafíos más comunes de este tipo de aplicaciones; por ejemplo brinda la posibilidad de utilizar SQL Azure o el servicio de Caching para manejar el estado de sesión a lo largo de la granja de servidores, así como mecanismos de persistencia no relacionales, infraestructura para mensajería y pub/sub, Content Delivery Network (CDN), etc.

 

Elasticidad

“Elasticidad” es la capacidad de una aplicación de agregar o quitar recursos dinámicamente en respuesta a la demanda.

Windows Azure ayuda enormemente a que las aplicaciones que escalan hacia afuera puedan ser muy elásticas, ya que permite agregar o quitar instancias de un rol en pocos minutos, de manera de poder abaratar los costos en momentos de poca demanda, pero incrementar el poder de cómputo cuando la demanda así lo requiera.

A fines de 2011, Microsoft patterns & practices publicó el Autoscaling Application Block, también conocido por su nombre en clave “Wasabi”. Es un componente que permite monitorear diferentes métricas de performance de nuestra aplicación, y a partir de reglas definidas por un operador, determinar y ejecutar automáticamente acciones para escalar horizontalmente, de manera tal de abaratar costos, pero sin sacrificar performance cuando se la necesita.

Wasabi permite, por ejemplo, cambiar la cantidad de instancias de acuerdo al horario, permitiendo definir recurrencias que tengan sentido en nuestro negocio (por ejemplo, aumentar la cantidad de instancias de mi sitio todos los viernes de 12 a 17 hs, que es cuando la mayoría de mis usuarios acceden al sitio para enviar sus reportes de gastos de la semana).

También permite monitorear métricas como el uso de CPU, la cantidad de mensajes en una cola de Windows Azure, etc., para comparar contra otros valores y decidir escalar horizontalmente ante cambios no predecibles en la demanda.

Wasabi incluye muchas funciones más, y además, al ser un componente en lugar de un servicio, tiene la capacidad de ser extendido mediante configuración o incluso código. Por ejemplo, podemos definir métricas de performance específicas a nuestro negocio, acciones para escalar hechas a medida, notificaciones, etc.

Para más información sobre Autoscaling en Windows Azure y Wasabi, ver aquí (en inglés): http://msdn.microsoft.com/en-us/library/hh680945(v=pandp.50).aspx

 

Sin balas de plata

Así usemos Wasabi para aumentar la elasticidad, es importante reiterar que escalar horizontalmente no es solo cuestión de desplegar nuestra aplicación en la nube y aumentar la cantidad de instancias; nuestra aplicación debe estar preparada para funcionar armónicamente con varias instancias interactuando entre ellas.

Hay arquitecturas y patrones que facilitan –aunque no garantizan- la creación de aplicaciones altamente escalables, distribuidas y elásticas. Un patrón de arquitectura que está teniendo mucho auge en la nube es CQRS (Command and Query Responsibility Segregation), que muchas veces es utilizado junto a otro patrón llamado Event Sourcing, comúnmente referidos en conjunto como CQRS/ES. La explicación de estos patrones va más allá de este artículo, pero los invito a leer más sobre ellos en el siguiente sitio que contiene ejemplos, videos y podcasts: http://cqrs.wordpress.com/

Microsoft patterns & practices comenzó un nuevo proyecto con el objetivo de ayudar a la comunidad a comprender estos patrones, ya que requieren un cambio importante de paradigma con respecto a las clásicas arquitecturas de 3 capas. Más información en el sitio oficial de p&p: http://cqrsjourney.github.com/

Recordar que no hay balas de plata: CQRS y Event Sourcing no son la solución a todos nuestros desafíos de escalabilidad. Hay muchos escenarios en los que los beneficios de estos patrones en particular no son tan claros, e incluso pueden llevar al fracaso si el equipo de desarrollo no tiene experiencia en este tipo de arquitecturas. Sin embargo, conocer estas arquitecturas puede ser muy útil incluso en pequeñas porciones de nuestro sistema, en lugar de ser una arquitectura de alto nivel que rige el 100% del mismo.

 

No hay límites de escalabilidad

Si bien no hay balas de plata para resolver todos los desafíos de desarrollo, sí hay mucha ayuda para resolverlos, y de la mano de Windows Azure surge la posibilidad de crear aplicaciones que comienzan pequeñas, y van creciendo en escala dinámicamente a medida que lo necesitan, sin necesidad de comprar el hardware de antemano para cubrir nuestros picos de demanda, y así pagar por el servicio de infraestructura sólo cuando es necesario.