NGINXaaS for Azure permite a las empresas ofrecer de forma segura aplicaciones de alto rendimiento en la nube. Basado en NGINX Plus, es un servicio totalmente gestionado que pasó a estar disponible de forma general en enero de 2023. Desde su lanzamiento y de cara al futuro, seguimos mejorando NGINXaaS for Azure mediante la incorporación de nuevas funcionalidades.
En este blog, destacamos algunas de las últimas funcionalidades de rendimiento y seguridad que le permiten aprovechar más ventajas de NGINX Plus sin tener que implementar, mantener ni actualizar sus propias instancias de NGINX Plus. Para obtener información general sobre NGINXaaS for Azure y sus funcionalidades globales, consulte Simplifique y acelere las migraciones a la nube con F5 NGINXaaS for Azure.
Figura 1: Descripción general de NGINXaaS for Azure
Protección del tráfico ascendente con mTLS
Aunque los proxies inversos requieren SSL/TLS para cifrar el tráfico del lado del cliente en la Internet pública, TLS mutuo (mTLS) resulta esencial para autenticar y garantizar la confidencialidad en el lado del servidor. Con la transición hacia un modelo de «confianza cero», también es necesario verificar que el tráfico hacia los servidores de origen no haya sido alterado ni interceptado.
Figura 2: mTLS con NGINXaaS
NGINXaaS for Azure ahora admite directivas de NGINX para proteger el tráfico ascendente con certificados SSL/TLS. Estas directivas no solo permiten mantener cifrado el tráfico ascendente mediante mTLS, sino también verificar que los servidores ascendentes presenten un certificado válido emitido por una autoridad de certificación de confianza.
Rotación de certificados
Un aspecto clave (nunca mejor dicho) del uso de certificados TLS con NGINXaaS for Azure es gestionar dichos certificados de forma segura mediante Azure Key Vault (AKV). AKV protege el material criptográfico confidencial y permite que NGINXaaS for Azure utilice esos certificados, al tiempo que evita la divulgación accidental o intencionada del material de claves a través del portal de Azure.
Figura 3: Rotación de certificados con Azure Key Vault
NGINXaaS for Azure ahora puede rotar certificados automáticamente en sus implementaciones de NGINX cada vez que se actualizan en AKV. Las nuevas versiones de los certificados se incorporan a sus implementaciones en un plazo de cuatro horas.
Proxy HTTP/2 (y opciones de protocolo adicionales)
Cierra los ojos y remóntate a 1997. Cantábamos «Tubthumping» de Chumbawamba, llevábamos nuestros vaqueros JNCO (o Modrobes, para los canadienses que nos lean) y se lanzó HTTP/1.1. Por aquel entonces, la mayoría de los usuarios finales accedía a Internet mediante un módem de acceso telefónico, las páginas web solo contenían unas pocas decenas de elementos y, en lo que respecta a la experiencia de usuario, el ancho de banda preocupaba mucho más que la latencia.
Veinticinco años después, una parte considerable de las aplicaciones web sigue utilizando HTTP/1.1 para servir contenido. Esto puede suponer un problema. Aunque HTTP/1.1 sigue funcionando, solo permite entregar un recurso por conexión a la vez. Mientras tanto, las aplicaciones web modernas pueden realizar cientos de solicitudes para actualizar una interfaz de usuario.
Aunque la mayoría de los usuarios dispone de un ancho de banda considerablemente mayor, la velocidad de transmisión de datos (limitada por la velocidad fundamental de la luz) no ha avanzado al mismo ritmo. Por tanto, la latencia acumulada de todas esas solicitudes puede afectar significativamente al rendimiento percibido de la aplicación. Los navegadores modernos abren varias conexiones TCP con el mismo servidor, pero las solicitudes de cada una de esas conexiones siguen procesándose de forma secuencial, lo que significa que un recurso lento puede retrasar todos los recursos que vienen detrás.
Echa un vistazo a la página de inicio de F5 cuando se carga utilizando únicamente HTTP/1.1:
Figura 4: acceso a F5.com mediante HTTP/1.1
¿Ves todas esas barras grises? Es un tiempo muy valioso que el navegador está desperdiciando mientras espera a que se establezca la sesión, se queda bloqueado por un único recurso lento o espera a que haya una nueva conexión TCP disponible.
Activemos HTTP/2 y volvamos a intentarlo:
Figura 5: La misma solicitud, pero usando HTTP/2
Mucho mejor. Todavía hay algunos recursos lentos, pero no están bloqueando otras solicitudes y se dedica mucho menos tiempo a esperar debido a retrasos relacionados con las colas. HTTP/2 mantiene la misma semántica de HTTP/1.1 con la que están familiarizados los navegadores web y los servidores, al tiempo que añade nuevas capacidades para abordar algunas de las causas de una percepción deficiente del rendimiento de las aplicaciones (por ejemplo, la priorización de solicitudes, la compresión de cabeceras y la multiplexación de solicitudes).
Dada una diferencia tan clara, NGINXaaS for Azure ahora permite atender las solicitudes de los clientes mediante HTTP/2. Las conexiones del lado del cliente tienen más probabilidades de verse afectadas por tiempos de ida y vuelta más largos, por lo que puede gestionar ese tráfico aprovechando las ventajas de HTTP/2 para reducir la latencia sin modificar los servidores ascendentes.
A pesar de lo que algunos profesionales del sector de las aplicaciones web puedan querer creer, reconocemos que existen otras opciones de protocolo además de HTTP. Por este motivo, el módulo gRPC de NGINX también está disponible ahora en NGINXaaS for Azure. Ofrece varias directivas de configuración para trabajar con tráfico gRPC, como la interceptación de errores, la manipulación de cabeceras y mucho más.
Para el tráfico que no sea HTTP/gRPC, el módulo stream ya está disponible en NGINXaaS for Azure. Este módulo permite usar un proxy y equilibrar la carga del tráfico TCP y UDP.
Compatibilidad con el balanceo de carga de capa 4 y capa 7
NGINXaaS for Azure ahora puede funcionar como equilibrador de carga nativo de la nube tanto de capa 4 para TCP/UDP como de capa 7 para HTTP/HTTP. ¿Por qué es importante? En lugar de implementar dos servicios o equilibradores de carga diferentes, NGINXaaS for Azure le permite implementar un único equilibrador de carga y configurarlo para que funcione en ambas capas al mismo tiempo, lo que simplifica su arquitectura en la nube y reduce sus costes.
Puede obtener más información sobre la configuración aquí.
Mayor capacidad (hasta 160 NCU)
NGINXaaS for Azure es un servicio basado en el consumo que se mide por horas y se factura mensualmente en unidades de capacidad de NGINX (NCU). Recientemente, duplicamos esa capacidad de implementación de 80 a 160 NCU. Los clientes pueden implementar un sistema más pequeño de 20 NCU y, si aumenta la carga de trabajo, ampliarlo hasta 160 NCU. Además, también tienen la opción de implementar hasta 160 NCU desde el principio.
Incorporación de directivas de NGINX Plus
Para facilitar la migración directa de una instalación local a una oferta en la nube totalmente gestionada, hemos añadido numerosas directivas de NGINX Plus. Consulte todas las directivas de NGINX Plus que admitimos en NGINXaaS for Azure aquí.
Empieza hoy mismo
Mejoramos y ampliamos constantemente las formas en que puede utilizar la tecnología de NGINX y F5 para proteger, distribuir y optimizar todas las aplicaciones y API, estén donde estén. Gracias a las funcionalidades mencionadas y a otras nuevas incorporadas a NGINXaaS for Azure, más usuarios de Azure pueden resolver numerosos problemas relacionados con aplicaciones y API aprovechando la potencia de NGINX Plus, sin la carga que supone gestionar una infraestructura adicional de máquinas virtuales o contenedores.
Si desea obtener más información sobre NGINXaaS for Azure, le recomendamos que consulte la documentación del producto. Si está listo para probar NGINXaaS for Azure, visite Azure Marketplace o póngase en contacto con nosotros para hablar sobre sus casos de uso.
Sobre el autor
Artículos relacionados del blog
Únete a F5 NGINX en AppWorld 2024
Descubre las numerosas razones para asistir al evento insignia de F5, que incluirá un emocionante anuncio sobre la cartera de productos NGINX.
Rotación de certificados SSL/TLS sin reinicios en NGINX Open Source
La función de diccionario compartido permite configurar NGINX sin necesidad de reiniciarlo al renovar los certificados SSL/TLS.
Exposición de APIs en Kubernetes
La unidad 2 de Microservices March 2022 se centra en cómo exponer tus API en Kubernetes. Aquí tienes enlaces a los recursos que necesitas: la retransmisión en directo del 14 de marzo, artículos de blog y otros recursos de preparación, y el laboratorio práctico «Protege las API de Kubernetes mediante la limitación de solicitudes».
NGINX Sprint 2.0: visión clara, código renovado y nuevos compromisos con el código abierto
Hoy, en NGINX Sprint 2.0, anunciamos cómo respaldaremos nuestra visión del futuro de las aplicaciones modernas con una mayor presencia en la comunidad de código abierto, incluida la participación en el proyecto comunitario Kubernetes, nuevos proyectos de software de código abierto y la arquitectura de referencia para aplicaciones modernas.
Presentamos NGINX Plus R22
NGINX Plus R22 incorpora nuevas funcionalidades, como la compatibilidad con OCSP para verificar la revocación de certificados en TLS mutuo, el uso de varios proveedores de identidad OIDC en una configuración, el seguimiento en tiempo real de la limitación de solicitudes y conexiones en el panel de NGINX Plus y mejoras en NGINX JavaScript.
Presentamos NGINX Plus R17
NGINX Plus R17 incorpora compatibilidad con la limitación de velocidad en dos fases y con TLS 1.3, la versión más reciente del protocolo Transport Layer Security. La configuración de OpenID Connect es más sencilla y NGINX ModSecurity WAF es el doble de rápido que antes. También se ha actualizado el módulo JavaScript de NGINX.