En Azure tenemos diferentes recursos que nos permiten configurar nuestra infraestructura con capacidades de Alta Disponibilidad, Balanceo de carga, Direccionamiento geográfico, gestión de la encriptación de SSL, Windows Firewal, etc. Entre ellos tenemos a Azure Traffic, Azure Load Balancer, Azure Application Gateway y el WAF asociado.
Ahora se ha presentado un nuevo recurso que aúna las funcionalidades anteriormente expuestas, y alguna más: Azure Front Door.
Configuración inicial
Siguiendo el tutorial de la propia documentación de Azure, he montado primero dos Web App en dos regiones diferentes (usa central y west europe); cada una con su propio App Plan de de tamaño B1 Linux; y su propio grupo de recursos. A continuación he añadido un nuevo grupo de recursos en west europe, donde he creado y configurado mi Front Door.
Primero he creado en host del FrontEnd, es decir el prefijo de la url por donde van a entrar mis usuarios. Luego he creado el pool del backend en donde he dado de alta las dos Web App, le he indicado que el protocolo es HTTPS, y que la sensibilidad a la latencia es de 100 milisegundos (luego te explico porqué). Por último he metido una única regla de enrutado.
Finalizada la configuración, y salvada, entro en la dirección del frontend y me devuelve un error 404, que no encuentra la página.
Dos errores molestos fácilmente corregibles
Lo primero que hago es revisar el pool de Web App para ver si algo estaba mal configurado… lo cual es así.
La primera Web App estaba metida erróneamente. Pero corregido esto, el AFD empezó a funcionar corréctamente hasta que apague una de las Web App, y muestra un error muy raro donde me indicaba que el servicio no estaba en servicio actualmente, y que lo intentara más tarde.
Descartado un problema en el pool, me fui a la regla de enrutado y me encontré que, mientras indicaba que el protocolo aceptado era HTTP solamente, en la parte del forwarding le había configurado HTTP Only. Lógicamente la funcionalidad no podía solucionar esta contradicción, ni darme un mensaje más «amigable», y se desconectó.
Asegurándome que en toda la configuración le indicaba HTTPS Only, todo volvió a funcionar corréctamente.
¿Porqué Front Door?
Personalmente, le he encontrado varias razones para utilizar este recurso en vez de la forma clásica de varios balanceadores de carga de Azure:
- Simplicidad. Tengo en un único recursos capacidades de alta disponibilidad; enrutado por geografía; balanceo por latencia, prioridad, peso o afinidad; caché del contenido estático; gestión del SSL; soporte de IPv6; etc.
- Velocidad. Utiliza la red privada de Microsof (la Microsoft Cloud) para el balanceo de carga y en caso de failover. Consiguiendo tiempos de respuesta muy inferiores a las soluciones basadas en otros tipos de recursos similares.
- Seguridad. Web Applications Firewall for Front Door. El cual es el mismo que el utilizado en el balanceador Application Gateway.
- Monitorización. Por defecto viene con los cinco medidores más importantes: el número de peticiones, el número de peticiones al pool, el volumen de tráfico de entrada y salida, y la salud del backend (las Web App).
- Coste. El propio recurso no cuesta dinero. Pero si el tráfico tanto de entrada como de salida.
- Sencillez. Montar una arquitectura básica con dos WebApp en alta disponibilidad me ha llevado unos 5 minutos. De la forma clásica, vía virtual networking, balanceador, web app, etc. Al menos, media hora.
- Tipo de host. No solamente me vale para mis App Service, sino que soporta cuentas de almacenamiento y servicios propios. Es decir, lo puedo utilizar para mis IIS en on premise, o para asegurarme que mis datos estén siempre disponibles.
Espero que sea de utilidad, y que te haya causado curiosidad.