Comunicación de cliente front-end

En un sistema nativo de la nube, los clientes front-end (aplicaciones móviles, web y de escritorio) requieren un canal de comunicación para interactuar con microservicios de back-end independientes.

¿Cuáles son las opciones?

Para simplificar las cosas, un cliente front-end podría comunicarse directamente con los microservicios back-end, que se muestra en la figura 4-2.

Figura 4-2. Dirigir la comunicación de cliente a servicio

Con este enfoque, cada microservicio tiene un punto de conexión público al que pueden acceder los clientes front-end. En un entorno de producción, colocaría un equilibrador de carga delante de los microservicios, enrutando el tráfico proporcionalmente.

Aunque es fácil de implementar, la comunicación directa de cliente solo sería aceptable para aplicaciones de microservicio simples. Este patrón combina estrechamente los clientes front-end con los servicios back-end principales, abriendo la puerta para muchos problemas, entre los que se incluyen:

• Susceptibilidad del cliente a la refactorización del servicio back-end.
• Una superficie de ataque más amplia al estar expuestos directamente los servicios principales de back-end.
• Duplicación de problemas transversales en cada microservicio.
• Código de cliente demasiado complejo: los clientes deben realizar un seguimiento de varios puntos de conexión y controlar los errores de forma resistente.

En su lugar, un patrón de diseño en la nube ampliamente aceptado es implementar un servicio de puerta de enlace de API entre las aplicaciones front-end y los servicios back-end. El patrón se muestra en la figura 4-3.

Figura 4-3. Patrón de puerta de enlace de API

En la ilustración anterior, tenga en cuenta cómo el servicio API Gateway abstrae los microservicios principales de back-end. Implementado como API web, actúa como proxy inverso y enruta el tráfico entrante a los microservicios internos.

La puerta de enlace aísla al cliente de la creación de particiones y refactorización del servicio interno. Si cambia un servicio back-end, puede acomodarlo en la puerta de enlace sin dar problemas al cliente. También es la primera línea de defensa para cuestiones transversales, como la identidad, el almacenamiento en caché, la resistencia, la medición y la limitación. Muchos de estas cuestiones transversales se pueden descargar de los servicios principales back-end a la puerta de enlace, lo que simplifica los servicios back-end.

Se debe tener cuidado para que la puerta de enlace de API sea sencilla y rápida. Normalmente, la lógica de negocio se mantiene fuera de la puerta de enlace. Una puerta de enlace compleja corre el riesgo de convertirse en un cuello de botella y, finalmente, un monolito. Los sistemas más grandes suelen exponer varias puertas de enlace de API segmentadas por tipo de cliente (móvil, web, escritorio) o funcionalidad de back-end. El patrón Backend para Frontends proporciona una directriz para implementar varias puertas de enlace. El patrón se muestra en la figura 4-4.

Figura 4-4. Patrón Back-end para front-end

Tenga en cuenta en la ilustración anterior cómo se envía el tráfico entrante a una puerta de enlace de API específica, en función del tipo de cliente: web, móvil o aplicación de escritorio. Este enfoque tiene sentido a medida que las funcionalidades de cada dispositivo difieren significativamente en el factor de forma, el rendimiento y las limitaciones de visualización. Normalmente, las aplicaciones móviles exponen menos funcionalidad que las aplicaciones de escritorio o explorador. Cada puerta de enlace se puede optimizar para que coincida con las capacidades y la funcionalidad del dispositivo correspondiente.

Puertas de enlace sencillas

Para empezar, puede crear su propio servicio de puerta de enlace de API. Una búsqueda rápida de GitHub proporcionará muchos ejemplos.

Para aplicaciones .NET sencillas nativas de nube, puede considerar el Gateway de Ocelot. Código abierto y creado para microservicios de .NET, es ligero, rápido y escalable. Al igual que cualquier puerta de enlace de API, su funcionalidad principal es reenviar las solicitudes HTTP entrantes a los servicios de bajada. Además, admite una amplia variedad de funcionalidades que se pueden configurar en una canalización de middleware de .NET.

YARP (otro proxy inverso) es otro proxy inverso de código abierto dirigido por un grupo de equipos de productos de Microsoft. Descargable como paquete NuGet, YARP se conecta al marco de ASP.NET como middleware y es muy personalizable. Encontrará YARP bien documentado con varios ejemplos de uso.

En el caso de las aplicaciones nativas de la nube empresarial, hay varios servicios de Azure administrados que pueden ayudar a iniciar sus esfuerzos.

Puerta de enlace de aplicaciones Azure

Para requisitos de puerta de enlace simples, puede considerar Azure Application Gateway. Disponible como servicio PaaS de Azure, incluye características básicas de puerta de enlace, como el enrutamiento de direcciones URL, la terminación SSL y un firewall de aplicaciones web. El servicio admite funcionalidades de equilibrio de carga de nivel 7 . Con la capa 7, puede enrutar las solicitudes en función del contenido real de un mensaje HTTP, no solo paquetes de red TCP de bajo nivel.

En este libro, evangelamos el hospedaje de sistemas nativos en la nube en Kubernetes. Un orquestador de contenedores, Kubernetes automatiza la implementación, el escalado y los aspectos operativos de las cargas de trabajo contenedorizadas. Azure Application Gateway se puede configurar como puerta de enlace de API para el clúster de Azure Kubernetes Service .

El controlador de entrada de Application Gateway permite que Azure Application Gateway funcione directamente con Azure Kubernetes Service. En la figura 4.5 se muestra la arquitectura.

Figura 4-5. Controlador de entrada de Application Gateway

Kubernetes incluye una característica integrada que admite el equilibrio de carga HTTP (nivel 7), denominado Ingress. La entrada define un conjunto de reglas para la forma en que las instancias de microservicio dentro de AKS se pueden exponer al mundo exterior. En la imagen anterior, el controlador de entrada interpreta las reglas de entrada configuradas para el clúster y configura automáticamente Azure Application Gateway. En función de esas reglas, Application Gateway enruta el tráfico a los microservicios que se ejecutan dentro de AKS. El controlador de entrada escucha los cambios en las reglas de entrada y realiza los cambios adecuados en Azure Application Gateway.

Azure API Management

Para sistemas nativos de nube de tamaño moderado a grande, puede considerar Azure API Management. Es un servicio basado en la nube que no solo resuelve las necesidades de la puerta de enlace de API, sino que proporciona una experiencia administrativa y desarrollador completa. API Management se muestra en la figura 4-6.

Figura 4-6. Azure API Management

Para empezar, API Management expone un servidor de puerta de enlace que permite el acceso controlado a los servicios back-end basados en reglas y directivas configurables. Estos servicios pueden estar en la nube de Azure, en el centro de datos local u otras nubes públicas. Las claves de API y los tokens JWT determinan quién puede hacer lo que. Todo el tráfico se registra con fines analíticos.

Para desarrolladores, API Management ofrece un portal para desarrolladores que proporciona acceso a servicios, documentación y código de ejemplo para invocarlos. Los desarrolladores pueden usar Swagger/Open API para inspeccionar los puntos de conexión de servicio y analizar su uso. El servicio funciona en las principales plataformas de desarrollo: .NET, Java, Golang, etc.

El portal del publicador expone un panel de administración donde los administradores exponen las API y administran su comportamiento. Se puede conceder acceso al servicio, supervisar el estado del servicio y recopilar la telemetría del servicio. Los administradores aplican directivas a cada punto de conexión para influir en el comportamiento. Las directivas son instrucciones pregeneradas que se ejecutan secuencialmente para cada llamada de servicio. Las directivas se configuran para una llamada entrante, una llamada saliente o se invocan tras un error. Las directivas se pueden aplicar en distintos ámbitos de servicio para habilitar la ordenación determinista al combinar directivas. El producto se distribuye con un gran número de directivas precompiladas.

Estos son ejemplos de cómo las directivas pueden afectar al comportamiento de los servicios nativos en la nube:

• Restringir el acceso al servicio.
• Exigir autenticación.
• Limite las llamadas desde un único origen, si es necesario.
• Habilite almacenamiento en caché.
• Bloquear llamadas desde direcciones IP específicas.
• Controlar el flujo del servicio.
• Convierta solicitudes de SOAP a REST o entre diferentes formatos de datos, como de XML a JSON.

Azure API Management puede exponer servicios back-end hospedados en cualquier lugar, en la nube o en el centro de datos. En el caso de los servicios heredados que puede exponer en los sistemas nativos de la nube, admite las API REST y SOAP. Incluso otros servicios de Azure se pueden exponer a través de API Management. Puede colocar una API administrada sobre un servicio de respaldo de Azure, como Azure Service Bus o Azure Logic Apps. Azure API Management no incluye compatibilidad integrada con el equilibrio de carga y se debe usar junto con un servicio de equilibrio de carga.

Azure API Management está disponible en cuatro niveles diferentes:

• Desarrollador
• Básico
• Estándar
• De primera calidad

El nivel Desarrollador está diseñado para cargas de trabajo y evaluación que no son de producción. Los demás niveles ofrecen progresivamente más potencia, funcionalidades y acuerdos de nivel de servicio (SLA). El nivel Premium proporciona compatibilidad con Azure Virtual Network y varias regiones. Todos los niveles tienen un precio fijo por hora.

La nube de Azure también ofrece un nivel sin servidor para Azure API Management. Conocido como nivel de precios por consumo, el servicio es una variante de API Management diseñada bajo el modelo de computación sin servidor. A diferencia de los planes de tarifa "asignados previamente", el nivel de consumo proporciona aprovisionamiento instantáneo y precios de pago por acción.

Habilita las características de la puerta de enlace de API para los siguientes casos de uso:

• Microservicios implementados mediante tecnologías sin servidor, como Azure Functions y Azure Logic Apps.
• Recursos del servicio de respaldo de Azure, como colas de Service Bus y temas, Azure Storage, etc.
• Microservicios en los que el tráfico tiene picos grandes ocasionales, pero sigue siendo bajo la mayoría del tiempo.

El nivel de consumo usa los mismos componentes subyacentes de API Management del servicio, pero emplea una arquitectura completamente diferente basada en recursos asignados dinámicamente. Se alinea perfectamente con el modelo informático sin servidor:

• No hay infraestructura que administrar.
• No hay capacidad sin uso.
• Alta disponibilidad.
• Escalado automático.
• El costo se basa en el uso real.

El nuevo nivel de consumo es una excelente opción para sistemas nativos en la nube que exponen recursos sin servidor como API.

Comunicación en tiempo real

La comunicación en tiempo real o push es otra opción para las aplicaciones front-end que se comunican con sistemas nativos de nube de back-end a través de HTTP. Las aplicaciones, como los indicadores financieros, la educación en línea, los juegos y las actualizaciones del progreso laboral, requieren respuestas instantáneas y en tiempo real del sistema backend. Con la comunicación HTTP normal, no hay forma de que el cliente sepa cuándo hay nuevos datos disponibles. El cliente debe sondear o enviar solicitudes continuamente al servidor. Con la comunicación en tiempo real , el servidor puede insertar nuevos datos en el cliente en cualquier momento.

Los sistemas en tiempo real suelen caracterizar los flujos de datos de alta frecuencia y un gran número de conexiones de cliente simultáneas. La implementación manual de la conectividad en tiempo real puede convertirse rápidamente en compleja, lo que requiere una infraestructura no trivial para garantizar la escalabilidad y la mensajería confiable a los clientes conectados. Podría encontrarse administrando una instancia de Azure Redis Cache y un conjunto de equilibradores de carga configurados con sesiones permanentes para la afinidad de cliente.

Azure SignalR Service es un servicio de Azure totalmente administrado que simplifica la comunicación en tiempo real para las aplicaciones nativas de la nube. Los detalles de implementación técnica, como el aprovisionamiento de capacidad, el escalado y las conexiones persistentes, se abstraen. Se administran por usted con un contrato de nivel de servicio del 99,9 %. Te centras en las características de la aplicación, no en los detalles técnicos de la infraestructura.

Una vez habilitado, un servicio HTTP basado en la nube puede insertar actualizaciones de contenido directamente en clientes conectados, incluidas las aplicaciones de explorador, móviles y de escritorio. Los clientes se actualizan sin necesidad de sondear el servidor. Azure SignalR abstrae las tecnologías de transporte que crean conectividad en tiempo real, incluidos WebSockets, eventos Server-Side y Long Polling. Los desarrolladores se centran en enviar mensajes a todos o subconjuntos específicos de clientes conectados.

En la figura 4-7 se muestra un conjunto de clientes HTTP que se conectan a una aplicación nativa de nube con Azure SignalR habilitado.

Figura 4-7. Azure SignalR

Otra ventaja de Azure SignalR Service incluye la implementación de servicios nativos en la nube sin servidor. Quizás el código se ejecute a petición con desencadenadores de Azure Functions. Este escenario puede ser complicado porque el código no mantiene conexiones largas con clientes. Azure SignalR Service puede controlar esta situación, ya que el servicio ya administra las conexiones.

Azure SignalR Service se integra estrechamente con otros servicios de Azure, como Azure SQL Database, Service Bus o Redis Cache, lo que abre muchas posibilidades para las aplicaciones nativas de la nube.