Azure Web Apps o Cloud Services

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 hemos hecho 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.

DESPLIEGUE

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.

deployment_ci

Un Cloud Service sin embargo está mas limitado en cuanto a la forma de despliegue, ahora mismo si queremos configurar “Continuous Delivery” solamente tenemos la opción de Visual Studio Online o 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 hablamos de Slots 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 Web Apps tenemos el Slot de producción y podemos tener hasta 5 slots más en el caso de la Standard y 1 slot más en el caso de la básica. Los slots son completamente funcionales y pueden ser utilizados simplemente    añadiendo –nombrestaging 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.net2.

Un escenario probable, es que ya hayamos probado nuestra aplicación y solamente queremos 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 configurado automáticamente se hace un swap a producción sin que tengamos que realizar ninguna acción manual. (Actualmente el auto-swap solo funciona)

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/B. Imaginé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 proporciona una mayor capacidad de control que las Web Apps, ya que nos permite 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 nuestro 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 Deployment user.

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 tenemos que tener en cuenta a la hora de decidirnos si usar Web Apps o Cloud Services es la necesidad o no de instalar .msi personalizados o ejecución de Sart-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 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 es muy necesario, estando más indicado para un Worker Role.

Los tipos de máquina soportados en un Web App estan 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 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”.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>