HCS crea una capa de aplicação front-end flexible con NGINX

Una agencia gubernamental nacional de los Países Bajos con una variedad diversa de partes interesadas y usuarios quería trasladar sus flujos de trabajo de procesos basados en papel a una infraestructura digital moderna. Esto permitiría a la agencia moverse más rápidamente y simplificar la vida de sus usuarios y empleados.

¿El desafío? La agencia permitió que cada localidad participante diseñara procesos y requisitos algo únicos. Inicialmente, la agencia había realizado un gran esfuerzo para crear una aplicação monolítica integral con numerosas personalizaciones. El primer esfuerzo fracasó bajo el peso de la hiperpersonalización: “muerte por mil requisitos”. Compañía HCS, una consultora de TI holandesa especializada en tecnologías de código abierto y Red Hat®, fue elegida para probar nuevas formas de digitalizar los procesos de la agencia con un enfoque diferente.

Reconstrucción simple: Microfront-ends, contenedores y microservicios componibles

El equipo de DevOps de la agencia trabajó en el proyecto con Benoit Schipper, ingeniero líder en confiabilidad del sitio (SRE) en HCS. Juntos comenzaron por analizar más profundamente el problema que estaban resolviendo. Los usuarios, desde funcionarios gubernamentales hasta abogados, contadores y ciudadanos comunes, necesitan iniciar sesión en la aplicación de la agencia, verificar el estado de un proyecto o proceso y cargar un PDF. Benoit y el equipo decidieron construir una base simple como punto de partida para la solución. Benoit explica: “Analizamos eso y dijimos: ‘Hagamos algo muy genérico, y para cualquier pedido especial podemos construir a partir de esa base genérica’”. El equipo de DevOps también quería asegurar la base para el futuro, garantizando la escalabilidad tanto dentro de la infraestructura existente como para ubicaciones y aplicações adicionales que pudieran necesitarse en el futuro.

Benoit y su equipo delinearon ese futuro y llegaron a una arquitectura novedosa de front-ends muy pequeños (micro) que pueden combinarse en diferentes aplicações asignadas a servicios pequeños y distintos (microservicios) en el back-end. “Optamos por los microservicios porque con esa arquitectura estamos preparados para ir a la nube y escalar cuando la empresa crezca mucho”, afirma Benoit. “Separamos el rompecabezas en piezas más pequeñas que pudiéramos pegar juntas”.

La primera decisión en torno a la implementación fue pasar de los servidores Microsoft Windows en un entorno dedicado a un entorno basado en contenedores en la nube, que es más adecuado para microservicios componibles y flexibles. El equipo eligió Red Hat OpenShift® como plataforma de contenedores.

Hubo dos factores fuertes a favor de OpenShift. En primer lugar, la larga experiencia de RedHat trabajando con gobiernos facilitó la obtención de la aprobación gubernamental para el diseño. En segundo lugar, OpenShift incluye muchas herramientas y aplicações diseñadas para facilitar la construcción y el mantenimiento de microservicios y arquitecturas de microservicios, entre las que se incluyen:

• Red Hat Ceph® Storage : un servicio de almacenamiento de blobs accesible a través de una API compatible con S3
• Red Hat AMQ Broker : un servicio de bus de mensajes para administrar la carga de trabajo y el estado de las aplicação , así como para poner en cola a los trabajadores.
• Soporte integrado y certificado para Kubernetes: importante para una mayor preparación para el futuro si HCS y la agencia determinan que Kubernetes es la herramienta adecuada para la orquestación de contenedores

De Windows a Linux, .Net Core y NGINX de código abierto

Pasar a contenedores significó reemplazar el back end .Net anterior de la agencia, que funcionaba en servidores Windows. Afortunadamente, fue una transición fácil a .Net Core , una versión de .Net optimizada para contenedores. Un beneficio adicional es que los desarrolladores de la agencia pueden seguir codificando en los lenguajes y marcos de aplicação de Windows con los que están familiarizados.

El equipo de DevOps creó un conjunto básico de API REST para acceder a los servicios de backend de .Net Core. Las API son el pegamento que mantiene unidas la funcionalidad y la lógica de la aplicação y los micro front-ends. Para el entorno front-end, el equipo eligió AngularJS debido a su amplia aceptación entre las organizaciones gubernamentales como un marco de JavaScript sólido y confiable con una comunidad sólida.

Para crear una capa de enrutamiento cohesiva para el tráfico y las llamadas API entre el front-end y el back-end, el equipo exploró varias opciones antes de decidirse por NGINX Open Source debido a su versatilidad. Las páginas del sitio web de la agencia se construyen sobre la marcha como micro front-end incorporando elementos de contenido y usando la misma lógica CSS para "adaptar" múltiples servicios back-end. Para el usuario, parece que todo ocurre dentro de la misma aplicação, "pero en realidad usamos proxy inteligente y reescrituras con NGINX. Para llenar la pantalla con la información adecuada para el front-end, realizamos llamadas a la API del back-end a través de NGINX", explica Benoit.

Para exponer la aplicação al Internet público, Benoit implementó una instancia F5 NGINX Plus como servidor web y proxy inverso en una máquina virtual que funcionaba en la DMZ de la agencia. Explica por qué NGINX Plus es la opción adecuada: “Necesitábamos TLS 1.3 y queríamos avanzar rápidamente. Era asequible en comparación con los dispositivos dedicados y podíamos agregar licencias fácilmente”.

Benoit destaca que para la agencia, “NGINX funciona como un servidor web, un proxy y una puerta de enlace API básica para nuestro nivel de aplicação . Es realmente una navaja suiza™ que puede hacer casi cualquier cosa. Por eso lo usamos.” Por ejemplo, para recuperar un PDF cargado, los usuarios seleccionan el PDF que necesitan de los documentos cargados en su cuenta y la aplicação de entrega de PDF envía una solicitud al servicio de recuperación de PDF de back-end conectado al almacén de objetos de Ceph. Ceph devuelve la URL única de la ubicación del PDF en el almacén de objetos, en el que el usuario hace clic para verlo o descargarlo.

Dado que la aplicação es de misión crítica, el equipo diseñó una arquitectura de alta disponibilidad activa-activa con todas las aplicações ejecutándose en al menos dos clústeres. Esto proporciona redundancia para todos los servicios, microfrontends y API, lo que garantiza que sigan funcionando en caso de una interrupción en uno de los clústeres.

Para mejorar el rendimiento y habilitar un plano de control para las aplicações compuestas que abarcan múltiples servicios, el equipo utiliza el bus de mensajes AMQ Broker para configurar temas y colas para los servicios. “Así que, si algo se puede ejecutar en segundo plano, lo hacemos en segundo plano”, afirma Benoit. “Si llega un mensaje y es necesario ajustar algunos datos del método, tenemos oyentes que pueden procesar algo o encontrar los trabajadores para ejecutar el proceso”. Para garantizar un estado consistente para los usuarios en todos los clústeres, el equipo conservó su infraestructura de base de datos Microsoft SQL Server de alta disponibilidad existente para mantener el estado del pod y habilitar la persistencia de la sesión.

Diseño para observabilidad, escalabilidad y flexibilidad

Para facilitar la observación, Benoit recomendó Grafana como el panel nativo de la nube. Para obtener métricas NGINX, el equipo de DevOps aprovecha el NGINX Prometheus Exporter en un sidecar emparejado con cada pod. El exportador extrae métricas de capa 4 del módulo NGINX Open Source Stub Status y la API NGINX Plus , combina cada una con una cadena, crea un par clave-valor y envía el par a Prometheus . Desde allí, el par se publica en una instancia de Grafana separada que está expuesta solo a desarrolladores y equipos de DevOps. "Es increíble. Puedo crear paneles y recopilar métricas en un solo lugar en todas mis instancias NGINX Open Source y NGINX Plus. El equipo de DevOps tiene el control. “Pueden ver qué está funcionando y recibir alertas sobre problemas”, afirma Benoit.

El equipo también utiliza las métricas para la gestión del rendimiento de la aplicação. Prometheus genera alertas para excepciones y conexiones no controladas en las aplicações, que indican que no hay suficientes trabajadores en ejecución. Benoit ha vinculado las métricas a la función de escalamiento automático en OpenShift. Él explica: “Configuré NGINX para una cierta cantidad de trabajadores y calculé la RAM y la CPU necesarias. Si la carga de trabajo se vuelve demasiado alta en comparación con esa línea base, OpenShift aumenta automáticamente la escala y me envía una alerta”.

Cuando una prueba de penetración indicó que las aplicações no utilizaban una política de seguridad de contenido (CSP) sólida, el equipo pudo configurar NGINX Open Source y NGINX Plus con políticas para la aplicación en línea de CSP. También configuraron una configuración personalizada para extraer información de registro JSON de la plataforma de contenedores y enviarla a la plataforma de registro Splunk para análisis histórico y mantenimiento de registros.

Mejorando la experiencia del desarrollador

Para los desarrolladores front-end que utilizan Google Analytics y Lighthouse , HCS hizo posible incluir verificaciones de Lighthouse en el pipeline de la agencia, codificadas en configuraciones NGINX. “Rápidamente vimos que podíamos lograr mejoras de rendimiento significativas al cambiar a la biblioteca de compresión GZIP”, afirma Benoit, y el resultado es una mejora del 60% en la latencia de la aplicação .

Además, con la nueva arquitectura los desarrolladores ahora están en contacto directo con los usuarios finales porque tienen una visibilidad detallada del comportamiento en tiempo real. “El ciclo de retroalimentación es mucho más rápido y, si sucede algo y es necesario cambiarlo, podemos ponerlo en producción en tan solo un día. “Eso es muy rápido para los gobiernos, donde antes los cambios tomaban meses o incluso años”, dice Benoit. “Para nuestros desarrolladores, esto es como la noche y el día”.

La pila tecnológica

• Back-end – .Net Core
• Interfaz – AngularJS
• Redes (servidor web, proxy inverso, puerta de enlace API, controlador de ingreso, balanceador de carga global): NGINX de código abierto , NGINX Plus , F5 BIG‑IP , HAProxy (en OpenShift)
• Base de datos : Microsoft SQL Server , Red Hat Ceph Storage , InfluxDB para datos de Lighthouse
• CI/CD – Azure DevOps
• Infraestructura : Red Hat OpenShift , contenedores Linux
• Mensajería : Red Hat AMQ Broker (Active MQ de código abierto)
• Observabilidad y métricas : Grafana y Prometheus
• Registro – Splunk

Introducción

¿Quieres duplicar los excelentes resultados de este proyecto construyendo tu pila tecnológica en NGINX Plus? Comience hoy su prueba gratuita de 30 días o contáctenos para analizar sus casos de uso .