Primeros pasos para una arquitectura en Azure

La nube está cambiando la forma en que desarrollamos aplicaciones. Ya no construimos aplicaciones monolíticas, ahora dividimos nuestras aplicaciones en componentes más pequeños para así aprovechar mejor las capacidades que nos ofrece la nube. Así mismo cada vez más integramos con servicios de terceros que se encuentran disponibles como APIs.

Esto nos plantea nuevos retos a nuestras soluciones tales como: estado distribuido, diferentes APIs con sus propios sistemas de autenticación, operaciones asíncronas.

En este entorno nuestras aplicaciones tienen que ser resilientes, recuperarse de forma ágil de los fallos; el despliegue debe de estar automatizado y ser predecible; la monitorización y la evaluación de métricas clave es vital para la solución y prevención de problemas.

A lo largo de este artículo repasaremos los pilares básicos de una arquitectura robusta para ser desplegada en la nube, así como algunas de las herramientas que Azure nos ofrece, siguiendo las recomendaciones de Microsoft y ampliándolas con nuestra experiencia en cliente.

Los pilares de una solución en la nube

No existe una única arquitectura válida a la hora de diseñar la arquitectura de una solución en la nube, pero sí existen algunos criterios comúnmente aceptados que podemos aplicar de forma independiente a las tecnologías o proveedores de servicios en la nube que deseemos utilizar.

Los cuatro pilares básicos de una arquitectura en la nube son:

• Seguridad
• Escalabilidad
• Disponibilidad
• Operaciones

Si estos cuatro pilares son sólidos, podremos diseñar una arquitectura que sea confiable, segura y flexible sobre la que construir nuestras aplicaciones.

Seguridad

El punto central de toda nuestra infraestructura tecnológica son los datos. Toda aplicación que diseñemos se basa en el proceso, catalogación y presentación de datos, y estos son claves para cualquier negocio. Por tanto, asegurarnos de que personas no deseadas no pueden consultar o manipular nuestros datos es el pilar principal de una buena solución en la nube. Estos son los puntos clave de la seguridad de una aplicación:

1. Autenticación/Autorización:

Todas nuestras aplicaciones deben requerir un proceso de autenticación que nos permita verificar la identidad del usuario, pero esto por sí solo no es suficiente: es recomendable asignar roles que permitan gestionar diferentes niveles de acceso a la información para cada usuario.

Azure nos ofrece una gran herramienta para gestionar tanto la autenticación y autorización, Azure AD. Con Azure AD podemos gestionar la seguridad de nuestras aplicaciones, aplicando protocolos de autenticación multifactor de forma contextual, podemos realizar controles tales como confiar en un login clásico de usuario y contraseña desde el equipo personal del usuario en nuestra red, pero requerir un segundo factor tal y como un código de verificación por SMS cuando el usuario está accediendo desde una red externa o un equipo desconocido.

2. Encriptación:

Para garantizar la integridad de nuestros datos y que nadie tenga un acceso no autorizado a nuestros datos, estos deben de estar encriptados tanto en tránsito como en reposo. Azure nos ofrece por defecto la encriptación de datos mientras estos se encuentren almacenados en la nube mediante certificados gestionados por Microsoft.

Para la encriptación en tránsito, es habitual que todas las webs y API que consultamos en nuestro día a día sean accesibles mediante HTTPS, que es el protocolo estándar para la encriptación de información en tránsito. Para las soluciones desplegadas en PaaS (Platform as a Service) que implementemos en Azure, Microsoft nos ofrece tanto la posibilidad de tráfico encriptado mediante certificados gestionados; si nuestras aplicaciones estuviesen desplegadas en IaaS (Infraestructure as a Service), nosotros tendremos que gestionar nuestros propios certificados. Más adelante entraremos en más detalle sobre qué son PaaS y IaaS y sus diferentes casos de uso.

3. Privacidad en las comunicaciones

Cada puerto que esté abierto en internet es susceptible a cualquier tipo de ataque, desde intentos de ejecución de código malicioso a ataques de denegación de servicio. Por eso, queremos asegurarnos de que la menor cantidad de servicios posible es accesible desde internet. Azure nos permite crear redes virtuales dentro del propio Azure e integrarlo en nuestra red a través de VPN, permitiendo un acceso seguro a la información que se encuentre en nuestros sistemas; así mismo, estas redes virtuales permiten que los diferentes servicios de Azure se comuniquen entre ellos sin necesidad de exponer una IP pública visible desde internet a través de la tecnología Private Link.

Abajo podemos ver un ejemplo de cómo podemos tener varias redes virtuales integradas con nuestra red On premise y consumir servicios de Azure tales como un Azure SQL sin exponer ninguna IP pública.

Por último, tanto para gestionar los puntos de entrada a nuestra aplicación desde el exterior como para asegurarnos que dentro de nuestras redes virtuales el tráfico está bien segmentado disponemos de herramientas: a cada red virtual podemos asignarle un Network Security Group, que nos permite definir reglas de tráfico de entrada y salida para cada puerto todos los servicios PaaS de Azure tales como Azure Web App o Azure SQL ofrecen firewall integrados que nos permiten filtrar qué IPs pueden acceder a ellos.

4. Escalabilidad

Una aplicación moderna debe de ser capaz de rendir en horas pico y adaptarse a subidas repentinas de demanda. Tanto si estamos utilizando tecnologías más tradicionales basadas en servidor (IaaS) o estamos aprovechando las ventajas de las tecnologías serverless (PaaS), Azure nos ofrece alternativas para cubrir nuestras necesidades. Según nuestras necesidades tenemos balanceadores de carga para aplicaciones publicadas tanto a nivel global como regional a nivel de aplicación (L7, ideal para APIs y contenido web) y a nivel de transporte (L4, ideal para servicios como bases de datos), esto nos permite construir arquitecturas con gran flexibilidad y un alto nivel de complejidad.

1. Traffic Manager: Es un balanceador global a nivel de DNS que nos permite distribuir el tráfico a través de nuestro backend en base a las políticas de enrutado que hayamos definido. Podemos seguir criterios tales como: redirección al servidor con menor latencia, enrutado a un servidor principal con un servidor de respaldo en caso de fallo del principal o enrutado hacia la región de Azure más cercana en base a la localización de la IP de llamada. Nos permite redirigir tráfico entre distintas regiones de Azure e incluso entre Azure y servidores On-Premise y es indiferente al protocolo de comunicación utilizado.
2. Azure Front Door: Azure Front door es un balanceador global L7. Recoge las llamadas HTTP entrantes y las redirige al servidor disponible más cercano en base a criterios de menor latencia. Además, nos permite gestionar un punto de entrada único a diferentes backends funcionando como un proxy inverso, siendo ideal para una arquitectura basada en microservicios.
3. Application gateway: Es un balanceador regional L7, nos permite publicar conectar a varios backends dentro de una misma región, manejando escenarios estándar como balanceo round robin, affinity cookies que permiten mantener una sesión abierta en un nodo específico o desplegar varias aplicaciones detrás de un único Gateway. Utilizado en combinación con Azure Front Door o Traffic Manager podemos tener un Application Gateway dentro de cada región al que se puede acceder desde una URL única, dando excelentes tiempos de respuesta y distribuyendo la carga de nuestras aplicaciones de forma eficaz.
4. Azure Load Balancer: Es un balanceador L4 que nos permite redirigir el tráfico dentro de una misma región de Azure, soporta comunicaciones por TCP y UDP y es ideal para balancear servicios que no soportan comunicaciones por HTTP, tales como servidores de bases de datos. Se puede combinar con Traffic Manager para tener servicios accesibles a nivel global a través de una dirección única con los menores tiempo de latencia posibles.

Monitorización

El cuarto pilar de una buena arquitectura en la nube son las operaciones, este pilar atañe a la monitorización de los sistemas para asegurar su rendimiento y la optimización de costes. Conocer los niveles de consumo de nuestras aplicaciones nos permiten ajustar el tamaño de nuestra infraestructura a nuestras necesidades.

Para asegurarnos de una monitorización eficiente primero necesitamos saber qué deseamos monitorizar y como interpretar nuestra información. Azure nos ofrece métricas detalladas en sus servicios PaaS sobre el consumo medio de memoria y procesamiento, tiempo de respuesta medio o porcentaje de error en llamadas sobre nuestras APIs. Así mismo existen herramientas que nos permiten obtener información similar en soluciones desplegadas en IaaS. Pero esta información por sí misma no nos dice gran cosa, no necesitamos un sistema que un sistema no crítico con poco uso tengo una respuesta inferior a 2 décimas en cada llamada; para una monitorización adecuada necesitamos un plan de acción y una serie de objetivos claros. A la hora de establecer un sistema de alertas exitoso y de verdadera utilidad necesitamos tener claros cuales son los objetivos de nuestra solución y cuáles son los indicadores de si estamos cumpliendo dichos objetivos.

Por ejemplo, un tiempo de respuesta por debajo de dos décimas suena bien, pero en una aplicación simple con un volumen bajo de usuarios puede ser un indicador de que puedo utilizar una infraestructura menos potente que me permita ahorrar costes; en un sistema complejo que integre varias piezas puede ser imposible. En cambio, en una aplicación que tenga que tomar decisiones en tiempo real sobre microtransacciones en bolsa es inaceptable.