Azure Web Apps vs Cloud Services (I)

WebApps

Todos los que estamos involucrados en el desarrollo de aplicaciones sobre la plataforma Microsoft Azure hemos tenido en algún momento la duda de si es más optimo para nuestra aplicación el uso de Azure Web Apps (“Los Azure Web Sites de toda la vida”) o si por el contrario necesitamos usar Cloud Services (para esta entrada del blog no vamos a meter las máquinas virtuales en la ecuación). Si esa pregunta nos la hacíamos hace unos cuantos meses la respuesta era fácil, en la mayoría de los casos veíamos que era necesario el uso de Cloud Services, porque las funcionalidades de las Azure Web Apps no cubrían todas nuestras necesidades. Sin embargo las Azure Web Apps han evolucionado considerablemente y eso nos permite tenerlas muy en cuenta a la hora de diseñar la arquitectura de nuestra solución.

Esta entrada es la primera de una serie en la que se analizarán la funcionalidades que nos proporcionan ambas soluciones. En este post analizaremos las características tanto de las Azure Web Apps como de los Cloud Services desde los siguientes puntos de vista:

  • Despliegue: opciones de despliegue, continuous delivery, slots, Trafic routing.
  • Control: remote desktop, kudu, instalación de .msi personalizados, start-up tasks.
  • Escalabilidad: autoscaling y cambio de tipo de máquinas en caliente.
  • Gestión de trabajos: Worker Roles y WebJobs.

DESPLIEGUE

Continuous delivery
Continuous delivery

Tenemos varias formas de desplegar una Azure Web App así como de automatizar este proceso. Por ejemplo podemos configurar un proceso de despliegue continuo con repositorios como Visual Studio Online, BitBucket, DropBox o GitHub. Si has trabajado con Azure Web Apps verás que el despliegue es muy rápido y normalmente no suele llevar mas de un par de minutos.

Un Cloud Service sin embargo está mas limitado en cuanto a la forma de despliegue, ahora mismo si queremos usar “Continuous Delivery” solamente tenemos la opción de utilizar Visual Studio Online, bien usando el repositorio de TFSVC o de Git.

Tenemos una opción alternativa que yo únicamente utilizaría en un entorno de desarrollo,  que es la de desplegar nuestro código mediante WebDeploy a un Cloud Service. La limitación que tiene esta opción es que solamente se realizará el despliegue a una instancia con lo que si tenemos varias, tendremos que hacerlo en todas ellas.

Si nos fijamos en los Slots donde podemos desplegar nuestra aplicación, veremos que las Web Apps proporcionan mucha más funcionalidad que los Cloud Services:

  • En el caso de los Cloud Services tenemos un slot de producción y un slot de staging, los cuales en cualquier momento se puede intercambiar mediante la opción “Swap”. Así tenemos una opción bastante rápida para poder realizar pruebas antes de desplegar a producción una nueva versión.

En el caso de las Azure Web Apps tenemos el Slot de producción y podemos tener hasta 5 slots más en el caso del plan de servicio Standard y 1 slot más en el caso del plan de servicio Básico. Los slots son completamente funcionales y pueden ser utilizados simplemente añadiendo el nombre del slot a la url. Si la url de nuestra Web App es mitienda.azurewebsites.net y hemos creado un slot llamado testing, podemos acceder a este mediante la url mitienda-testing.azurewebsites.net.

Un escenario probable, es que ya hayamos probado nuestra aplicación y solamente queramos utilizar el slot de staging para evitar una caída de servicio en el despliegue. En este caso las Web Apps nos permiten realizar un Auto-Swap. Esto consiste en que cuando desplegamos al slot de staging, automáticamente se hace un swap a producción sin que tengamos que realizar ninguna acción manual.  Por defecto esta opción esta desactivada y la tenemos que activar:

autoswap

  • Por último vamos a reseñar una funcionalidad más que nos proporcionan las Web Apps llamada Trafic Routing. Esto nos permite realizar pruebas de tipo A/BImaginémonos que queremos desplegar una funcionalidad nueva, pero no estamos totalmente seguros de como va a impactar al rendimiento de nuestra aplicación, la aceptación por parte de los usuarios o el impacto en las ganancias en nuestra tienda online. En este caso podemos desplegar dicha funcionalidad en un slot y configurar dicho slot para que reciba el 30% del tráfico de nuestra aplicación y que el slot de producción reciba el 70% restante. De esta forma podremos realizar “pruebas en producción” sin impactar al total de los usuarios.

Enrutamiento web apps

CONTROL

Los Cloud Services nos proporcionan una mayor capacidad de control que las Web Apps, ya que nos permiten conectarnos directamente a la máquina por escritorio remoto y realizar cualquier operación que necesitemos con permisos de administrador. Sin embargo que no podamos conectarnos a la máquina por escritorio remoto no quiere decir que no tengamos ningún control sobre nuestra Web app. Para suplir esa carencia, tenemos una herramienta de diagnóstico y resolución de problemas llamada KUDU.

Para poder acceder a esta herramienta simplemente tenemos que navegar a la siguiente url https://webappname.scm.azurewebsites.net, siendo webappname el nombre de nuestra Web App y logarnos con el usuario de Deployment .

kudu

Vemos que la consola de Kudu nos permite realizar acciones como capturar un volcado de memoria, interactuar con los procesos de nuestro host o ejecutar comandos de powershell o de línea de comandos entre otras opciones. Esto es bastante útil sobre todo en caso de que se produzca alguna incidencia en nuestra aplicación y tengamos que investigar cual es la causa.

Un requisito que debemos tener en cuenta a la hora de decidirnos si usar Azure Web Apps o Cloud Services es la necesidad o no de instalar .msi personalizados o la ejecución de Start-up tasks que requieran privilegios elevados. En el caso de necesitar alguna de estas opciones tendremos que recurrir a los Cloud Services debido a que las Azure Web Apps no nos permite realizar operaciones que requieran de privilegios elevados.

En la siguiente url http://bit.ly/1FDy3Cx puedes ver un ejemplo de código de como ejecutar una Start-up task pero realmente como verás las posibilidades que tenemos son muy limitadas.

ESCALABILIDAD

Desde un punto de vista de escalabilidad tanto un Cloud Service como una Web App comparten la misma funcionalidad básica, permitiendo escalar automáticamente basándonos en unos parámetros previamente definidos como número de instancias mínimas y máximas o umbrales de CPU. Los Cloud Service nos permiten alguna opción mas como autoescalado basándonos en mensajes en colas pero que para un Web Site probablemente no sea necesario, estando más indicado para un Worker Role.

Los tipos de máquina soportados en un Azure Web App están limitados a Small, Medium y Large mientras que un Cloud Service soporta bastantes más tipos de máquina. Deberemos tener muy en cuenta esta restricción en caso de que nuestra solución tenga alguna necesidad especial que nos obligue a utilizar máquinas con una mayor capacidad de proceso o de memoria.

En este punto las Web Apps tienen una pequeña ventaja con respecto a los Cloud Services y es que no necesitamos redesplegar nuestra aplicación si decidimos cambiar de tamaño de máquina pudiéndose hacer en “caliente”.

Otra cosa que debemos tener en cuenta es que los Azure Web Apps por defecto usan afinidad de sesión, esto quiere decir que una vez que una instancia nos sirve una petición, siempre nos va a atender el mismo servidor todas las peticiones para la sesión actual. Una pregunta que nos puede venir a la cabeza es, bueno entonces puedo usar variables de sesiones en memoria sin preocuparme debido a que siempre me va a atender el mismo servidor. La respuesta es ni se te ocurra :). En el caso de que el servidor se caiga, automáticamente otro servidor empezará a servirte las peticiones con lo que habremos perdido todo el contenido almacenado en las variables de sesión en memoria. Yo personalmente recomiendo el uso de algún tipo de caché distribuida como por ejemplo Redis.

En el caso de que queramos deshabilitar la afinidad, simplemente tendremos que añadir lo siguiente al web.config:

stickysessions

GESTIÓN DE TRABAJOS

Hasta hace poco tiempo si queríamos ejecutar tareas en Azure que procesaran mensajes en una cola o que realizara tareas planificadas, la única opción que teníamos era usar Worker Roles. Ahora mismo asociados a las Azure Web Apps tenemos los WebJobs.

Algunos definen estos Web Jobs como una especie de Worker Role ligero donde se recomienda su uso para procesos que consuman pocos recursos.

Ya que seguramente los Worker Roles los conocemos mejor, permíteme que haga hincapié en algunas de las características de los WebJobs:

  • Los WebJobs en sí son gratis pero dependiendo del Scheduler seleccionado podemos tener coste. Debido a que consumen recursos del Web App donde esté alojado, debemos tener en cuenta la necesidad de procesamiento por si tenemos que escala esta Web App.
  • Trabajan con colas prácticamente sin necesidad de código.
  • Gestionan automáticamente los mensajes envenenados («poison messages»). Se reintenta el procesamiento del mensaje 5 veces.
  • Son capaces de ejecutar los siguientes tipos:
    • .EXE, assemblies complilados con el sdk de WebJob
    • .cmd, .bat
    • .sh (bash)
    • .py (python)
    • .js (node)

Como acabamos de ver, en el caso de que necesitemos realizar alguna tarea en background ya no es obligatorio el uso de los Worker Roles sino que podemos empezar a tener en cuenta a los WebJobs.


Hemos visto una pequeña pincelada de lo que tanto los Azure Web Apps como los Cloud Services nos ofrecen pero seguro que se te habrá pasado por la cabeza al leer este artículo «bueno todo esto está muy bien pero cual me da mejor rendimiento», la respuesta en el próximo post :).

Gracias por leernos.