El App Service Plan (o simplemente el Service Plan) define cómo de grande es la máquina en la que vamos a ejecutar nuestra Web App, algo que podemos cambiar al vuelo por un plan más grande o más pequeño, al igual que podemos compartir el mismo Service Plan, entre varias Web Apps.
El Service Plan también nos va a determinar si son máquinas Windows ó Linux, el DataCenter, la RAM, la CPU, y el número máximo de Instancias que podemos arrancar, aunque hay más detalles. Por ejemplo, en un plan Basic podemos escalar horizontalmente hasta 3 Instancias, pero sólo de forma manual (Auto-Scale no está disponible, salvo que montemos un plan Standard o Premium).
Pero sobre todo, el Service Plan determinará los recursos que utilizaremos, que en Azure es por lo que pagamos (Pay as you go).
Una Azure App Service Web App (cordialmente, una Web App) en Microsoft Azure representa conceptualmente un Sitio Web de IIS (con su wwwroot, sus configuraciones, etc), ofrecido en un modelo PaaS (Platform as a Service). Y digo conceptualmente, porque realmente puede ser una App sobre Windows o sobre Linux, soportándose múltiples lenguajes como .NET, .NET Core, Java, Ruby, Node.js, PHP, or Python.
Por lo tanto, una Web App es algo más, no se limita a un simple Sitio Web de IIS. Es más potente, más fácil. Es PaaS. Nos olvidamos de la infraestructura, del qué hay debajo (ya no nos podremos conectar por RDP a las máquinas), de eso ya se encarga otro, pero tenemos Kudu (disponible añadiendo el prefijo dns scm a la url de nuestra Web App, ej: https://guillesql.scm.azurewebsites.net) para acceder a un montón de telemetría (ej: consola remota, explorador de archivos, explorador de procesos, site extensions, acceso a logs, etc.) y más cosas como los Web Jobs (poder ejecutar scripts variopintos de forma contínua o planificada como un cron), Backups y Restores integrados, App Settings, etc. Además, podemos disfrutar de las ventajas de sus capacidades de DevOps, del Desarrollo Continuo desde VSTS, GitHub, Docker Hub, etc., incluso desde el despliegue desde OneDrive/DropBox.
En lo relativo a la escalabilidad, una Web App se puede escalar de dos formas distintas, algo que realizaremos realmente a través de la configuración del App Service Plan al que pertenece:
- Vertical (Scale up). Consiste en añadir más Memoria y/o CPU, algo que podemos conseguir cambiando de App Service Plan. Por ejemplo, un App Service Plan S1 Standard ofrece 1 Core y 1,75GB de RAM, mientras que un S3 Standard sube a 4 Cores y 7GB de RAM.
- Horizontal (Scale out). Consiste en añadir más Instancias, ya sea de forma manual o bien de forma automática (Auto-Scale). El Auto-Scale (disponible sólo en planes Standard y Premium) se consigue creando una o varias reglas de escalado (ojo, si hay varias, una será la regla por defecto, y el resto tendrán un Schedule asociado), añadiendo o quitando Instancias en función de una métrica (ej: CPU) o estableciendo un número fijo de Instancias, que además pueden condicionarse en función de un Schedule (ej: noches, fines de semana, primera hora de la manaña, etc.). También podemos definir un periodo de Cool Down (vuelta a la calma), de tal modo, que por ejemplo hasta 15 minutos después de haber realizado un Auto-Escalado, no se realice ningún otro escalado automático, para permitir que el sistema se estabilice, y evitar que no se estén produciendo auto-escalados continuamente. También podemos configurar correos automáticos para informas de las operaciones de auto-escalado (actualmente desde la pestaña Notify). Así, con todo esto, podemos definir un conjunto de reglas para personalizar completamente el escalado de nuestra Aplicación Web a nuestras necesidades, y estar informados de su ejecución por correo electrónico. Hay que tener en cuenta, que el App Service Plan que estemos utilizando nos condiciona el número máximo de Instancias que podemos llegar a tener: 3 en los planes Basic (no permite Auto-Scale), 10 en los planes Standard, y 20 en los planes Premium.
Siendo puristas, cuando hablamos de Azure App Service Web Apps, podemos estar hablando de una Web App (una Aplicación Web tradicional), una Mobile App, una API App, o una Logic App.
En cualquier caso, la escalabilidad y muy especialmente el auto-escalado, resulta de vital importancia en el desarrollo de Aplicaciones Web modernas que tengan que soportar cargas de trabajo fuertes y dinámicas (que fluctúen en el tiempo), y que deseemos publicar en una Web App de Azure (bueno… en Azure, y fuera de Azure). Para poder aprovechar bien estas características, nuestra Aplicación Web debe implementar el patrón de diseño Sin Estado (Stateless Design Pattern).
Otro punto a tener en cuenta es la disponibilidad de Azure Traffic Manager, un balanceador de tráfico de red integrado como un servicio de Azure, que permite distribuir el tráfico de red entre distintos destinos (end-points), los cuales pueden estar dentro o fuera de Azure, sean Web Apps, Azure VMs, o cualquier otro tipo de destino tcp. Es una solución basada en DNS y en la monitorización de la salud/disponibilidad de los destinos (end-points), que nos permite elegir entre diferentes algoritmos de gestión de tráfico, permitiendo enrutar el tráfico al destino más cercano (ej: distribución geográfica), repartir el tráfico entre varios destinos (distribution: según los pesos asignados), o enrutado en caso de fallos (failover). El complemento perfecto para nuestras Web Apps.
Deployment Slots
Al igual que ocurre con las antiguas Aplicaciones de Azure Cloud Services (los tradicionales Web Roles y Worker Roles), con las Web Apps también tenemos los Deployment Slots, con la ventaja de que ahora podemos tener hasta cinco (el de production, más cuatro adicionales que podemos crear y asignarles el nombre que queramos), mientras que antes en Cloud Services sólo eran dos (Production y Staging).
La ventaja de los Deployment Slots, está en que podemos desplegar una versión de nuestra Aplicación sobre un Deployment Slot, y probarla hasta asegurarnos de su correcto funcionamiento. Posteriormente, podemos intercambiar dicho slot con otro (swap). Así, por ejemplo, una vez que hemos probado nuestro Slot de Test y estamos seguros de su correcto funcionamiento, podemos hacer un Swap con Producción, como método de paso a Producción. En caso de problemas, la marcha atrás es muy sencilla: otro Swap, y lo dejamos como estaba.
Web Jobs
Los Web Jobs son en cierto modo equivalentes a los Worker Role de Azure Cloud Services. Permiten desplegar un Script o Programa desde el propio Portal de Azure, para su ejecución continúa o desencadenada (manualmente o planificada como un cron), en segundo plano (background), dentro del contexto de la propia Web App (no tiene un coste asociado, al final, está consumiendo los recursos de la Web App).
Los Web Jobs pueden utilizarse por ejemplo en escenarios de mensajería asíncrona, de forma similar a como se utilizaría un Worker Role, aunque con las limitaciones propias de los entornos Web Apps (ej: no podemos instalar SW, no podemos acceder por RDP a los servidores, etc).
Conectividad VNet y On-Premise
Nuestras Web Apps se pueden conectar con nuestros recursos existentes en una Virtual Network (VNet) de Azure, a través de la opción VNET Integration, en cuyo caso necesitaremos que nuestra VNet tenga ya provisionado un Gateway (Azure Virtual Network Gateway), ya que realizará una conexión Point-to-Site.
También podemos conectar nuestras Web Apps con los recursos On-Premise (los que tenemos en nuestros Datacenters), a través de la opción Hybrid Connections, que utilizar los servicios de BizTalk (Azure BizTalk Services). En particular, vamos a conectar nuestra Web App con una correlación de un puerto TCP y Host, indiferentemente del sistema operativo y del protocolo en cuestión.
En ambos casos, estaremos creando un Tunel, a través del cual viajará cifrada nuestra información.
MySQL In-App for App Service
Otra funcionalidad interesante de las Web Apps, es la posibilidad de provisionar una base de datos MySQL como parte de la propia Web App, de una forma rápida y fácil. Tiene ciertas limitaciones, ya que será accesible sólo desde la Web App, conectándose a localhost.
Para su administración, podemos desplegar en nuestra Web App, la Site Extension de phpMyAdmin, y en apenas unos segundos lo tendremos ya disponible y configurado, para empezar trabajar.
Web App for Containers
Como es evidente en estos días, no podían faltar los Container que tan de moda se están poniendo, para lo cual, podemos desplegar una Web App for Containers. Así, podemos desplegar una imagen de Dockers, que tendremos funcionando en cuestión de segundos.
Al final, será una Web App, con alguna peculiaridad adicional, y asociada a un App Service Plan de Linux.
App Service Environment (ASE)
Una de las cosas que no podemos hacer con las Web Apps, es provisionarlas dentro de una determinada VNET. Tenemos disponibles algunas opciones de red en nuestra Web App, que nos permitirán por ejemplo, conectar nuestra Web App con una VNET que tengamos en Azure (necesitaremos provisionar un Gateway, si no lo teníamos antes). Esto sería lo más parecido, que puede ser útil en muchos casos, como por ejemplo para conectar nuestra Web App con un SQL que tengamos provisionado, pero seguimos sin poder establecer la VNET de nuestra Web App, sin poder personalizar su seguridad, etc.
Una Web App, simplemente tiene un end-point asociado a ella (una IP pública nateada), además de tener su propia configuración de red, que para nosotros es transparente (ni se ve, ni se toca). Por lo tanto, en algunos escenarios que necesitemos cumplir algunas normativas estrictas de seguridad (ej PCI), puede no ser suficiente.
El App Service Environment (ASE) que ofrece un entorno aislado y dedicado (single-customer), para ejecutar nuestras Aplicaciones Web de una forma segura y altamente escalable, que puede estar publicado o no a Internet. Es conceptualmente una Web App provisionada dentro de una VNET con algún otro detalle más, lo cual ofrece varias ventajas (especialmente de rendimiento, escalabilidad, y seguridad), al igual que tiene un coste distinto (lo quieres, lo pagas).
- Permite que nuestra Aplicación Web acceda a los recursos que tengamos en nuestra VNET, incluso también a recursos que tengamos disponibles a través de las conexiones Site-to-Site o ExpressRoute, pudiendo configurar la seguridad de nuestra VNET (ej: cumplir normativas de seguridad) para tener un control bastante fino del tráfico permitido de entrada y de salida.
- No es necesario que esté expuesto a Internet.
- Escalabilidad y Rendimiento: Con el nuevo modelo ASEv2 es posible escalar hasta 100 Instancias, con tamaños de worker de hasta 4 Cores y 14GB de RAM.
El App Service Environment (ASE) es una solución intermedia, entre las Web Apps (puro PaaS) y las Azure VM (puro IaaS), que nos permite obtener los beneficios de ambos modelos.
Poco más por hoy. Como siempre, confío que la lectura resulte de interés.
