Creando la próxima experiencia de NGINX, diseñada para la realidad de las aplicaciones modernas

Eric Braun

Como vicepresidente de Producto de NGINX, hablo con frecuencia con clientes y usuarios. Tanto si formas parte de un equipo de Operaciones de Plataforma como si eres arquitecto de Kubernetes, desarrollador de aplicaciones, CISO, CIO o CTO, he hablado con alguien como tú. En nuestras conversaciones, me habéis dado vuestra opinión sincera sobre NGINX, incluidos nuestros productos y modelos de precios y licencias, y habéis destacado tanto nuestros puntos fuertes como nuestras debilidades.

La principal conclusión que extrajimos es que nuestro enfoque de «NGINX es el centro del universo» no satisface adecuadamente las necesidades de nuestros usuarios. Habíamos estado desarrollando productos destinados a convertir NGINX en la «plataforma»: el plano de gestión unificado para todo lo relacionado con el despliegue de aplicaciones. Sabíamos que algunos de nuestros productos anteriores orientados a ese objetivo habían tenido poco uso y aceptación. Nos dijisteis que NGINX es un componente esencial de vuestra plataforma actual, ya sea de desarrollo propio o de otro tipo, pero que NGINX no era la plataforma. Por tanto, necesitábamos integrarnos mejor con el resto de vuestros componentes para facilitar el despliegue, la gestión y la protección de nuestros productos, con modelos de precios y consumo transparentes (y esto es importante). Y, por supuesto, hacer que todo ello fuera posible mediante una API.

El mensaje de fondo era claro: facilitar la integración de NGINX en sus flujos de trabajo, cadenas de herramientas y procesos existentes, sin imponer un enfoque concreto. Hemos tomado nota. En 2024, adoptaremos un enfoque mucho más flexible, sencillo, repetible y escalable para configurar y gestionar casos de uso relacionados con el plano de datos y la seguridad.

Vuestro deseo es totalmente comprensible. Vuestro mundo ha cambiado y sigue cambiando. Habéis pasado por varias etapas: de la nube a entornos híbridos, multinube e híbridos multinube. También se ha producido una transición de las máquinas virtuales a Kubernetes, y de las API a los microservicios y la informática sin servidor. Muchos habéis adoptado el enfoque «shift left», lo que ha generado una mayor complejidad. Cada vez más equipos disponen de más herramientas que requieren una mayor gestión, observabilidad y una seguridad sólida, todo ello para impulsar aplicaciones que deben poder escalar en cuestión de minutos, no de horas, días o semanas. Y el acelerador más reciente, la inteligencia artificial (IA), ejerce una presión considerable sobre las arquitecturas heredadas de aplicaciones e infraestructuras.

Qué tenemos previsto abordar en las próximas versiones de los productos NGINX

Aunque la base de los productos NGINX siempre ha sido extremadamente sólida, ha demostrado su eficacia en entornos reales y ha ofrecido un gran rendimiento, la forma en que nuestros usuarios podían utilizar, gestionar y supervisar todos los aspectos de NGINX no evolucionó al ritmo de los tiempos. Estamos actuando con rapidez para solucionarlo mediante el lanzamiento de un nuevo producto y un amplio abanico de nuevas funcionalidades. Daremos más detalles al respecto en la conferencia de F5 AppWorld 2024, que se celebrará del 6 al 8 de febrero. Estos son algunos de los problemas concretos que tenemos previsto abordar en las próximas versiones de nuestros productos.

Problema n.º 1: la diversidad de los entornos de implementación dificulta la gestión de las aplicaciones modernas

Hoy en día, los CIO y los CTO pueden elegir entre una amplia variedad de modalidades de despliegue de aplicaciones. Esto supone una ventaja, ya que ofrece muchas más opciones en términos de rendimiento, funcionalidades y resiliencia. Pero también es un inconveniente, porque esta diversidad genera complejidad y dispersión. Por ejemplo, gestionar aplicaciones que se ejecutan en AWS requiere configuraciones, herramientas y conocimientos internos diferentes de los necesarios para gestionar aplicaciones en Azure Cloud.

Aunque los contenedores han estandarizado gran parte del despliegue de aplicaciones, todo lo que se encuentra por debajo de ellos (o entra y sale de ellos) sigue siendo diferente. Como plataforma de facto para la orquestación de contenedores, se suponía que Kubernetes simplificaría ese proceso. Sin embargo, cualquiera que haya realizado despliegues en Amazon EKS, Azure Kubernetes Service (AKS) y Google Kubernetes Engine (GKE) puede confirmar que no se parecen en absoluto.

Nos habéis dicho que gestionar los productos de NGINX en esta enorme diversidad de entornos requiere una cantidad considerable de recursos operativos y genera ineficiencias. Y, francamente, los modelos de precios basados en licencias anuales dejan de funcionar en entornos dinámicos, donde se puede lanzar una aplicación en un entorno sin servidor, ampliarla en un entorno de Kubernetes y mantener un pequeño despliegue interno en la nube con fines de desarrollo.

Problema n.º 2: proteger aplicaciones que se ejecutan en múltiples entornos y abarcan distintos tipos de licencia resulta complicado

La complejidad de los distintos entornos puede dificultar la detección y supervisión de dónde se implementan las aplicaciones modernas, así como la posterior aplicación de las medidas de seguridad adecuadas. Puede que haya implementado NGINX Plus como balanceador de carga global y NGINX Open Source para varios microservicios, cada uno de ellos ejecutándose en nubes diferentes o sobre distintos tipos de aplicaciones. Además, podrían tener requisitos diferentes en materia de privacidad, protección de datos y gestión del tráfico.
Cada combinación añade un nuevo reto de seguridad. No existe una solución estándar e integral, lo que introduce complejidad operativa y la posibilidad de que se produzcan errores de configuración. Hay que reconocer que hemos contribuido a esa complejidad al no dejar claro qué tipos de seguridad pueden aplicarse a cada solución de NGINX.

Lo entendemos. Los clientes necesitan una única forma de proteger todas las aplicaciones que utilizan NGINX. Esta solución de seguridad unificada debe cubrir la gran mayoría de los casos de uso y emplear las mismas herramientas, paneles y procesos operativos en todos los entornos, ya sean en la nube, locales, sin servidor o de otro tipo. También reconocemos la importancia de avanzar hacia un enfoque de seguridad más inteligente, aprovechando la inteligencia colectiva de la comunidad de NGINX y la visión sin precedentes del tráfico global que tenemos la suerte de poseer.

Problema n.º 3: gestionar el coste de las aplicaciones modernas es complejo y genera desperdicio

En un mundo basado en el enfoque «shift-left», todas las organizaciones quieren dotar a los desarrolladores y profesionales de los medios necesarios para desempeñar mejor su trabajo, sin tener que abrir un ticket ni enviar un mensaje por Slack. Sin embargo, la realidad ha sido distinta. Se ha logrado abstraer mínimamente la complejidad mediante Kubernetes, la informática sin servidor y otros mecanismos para gestionar aplicaciones distribuidas y aplicaciones que abarcan entornos locales, en la nube y multinube. No obstante, estos avances se han limitado en gran medida al interior del contenedor y de la aplicación. No se han trasladado adecuadamente a las capas que rodean las aplicaciones, como las redes, la seguridad y la observabilidad, ni tampoco a la integración y la entrega continuas (CI/CD).

Ya he aludido a estos problemas en los puntos débiles anteriores, pero la conclusión es la siguiente: la complejidad conlleva grandes costes en términos de horas y trabajo tedioso, seguridad comprometida y resiliencia. Mantener sistemas cada vez más complejos supone un reto fundamental y requiere muchos recursos. La complejidad de los precios y las licencias añade otra capa de insatisfacción. NGINX nunca ha sido una empresa que haga «true-up» y penalice a los usuarios cuando consumen más de lo contratado por error.

Pero en un mundo de SaaS, API y microservicios, lo que quiere es pagar por uso, no por año, usuario ni licencia de sitio. Quiere un modelo de precios basado en el consumo que sea fácil de entender y se aplique a todos los productos y servicios de NGINX en toda su infraestructura tecnológica y cartera de aplicaciones. También quiere poder incorporar soporte y seguridad para cualquier módulo de código abierto que utilicen sus equipos, pagando únicamente por lo que necesite.

Esto requerirá algunos cambios en la forma en que NGINX empaqueta sus productos y fija sus precios. La solución definitiva debe ofrecer sencillez, transparencia y un modelo de pago por consumo, como cualquier otro SaaS. Os escuchamos. Y estamos preparando algo fantástico que abordará los tres problemas mencionados anteriormente.

Acompáñenos en App World 2024

Hablaremos de estas interesantes novedades en AppWorld 2024 e iremos implementando partes de la solución durante los próximos doce meses, como parte de nuestro plan y hoja de ruta a largo plazo.

Acompáñame en este viaje y conéctate a AppWorld para conocer en detalle todo lo que está por venir. Puedes beneficiarte del precio por inscripción anticipada hasta el 21 de enero. Consulta la página de inscripción de AppWorld 2024 para obtener más información. También estás invitado a reunirte con los responsables de NGINX y otros miembros de la comunidad la noche del 6 de febrero en la oficina de F5 en San José, donde pasaremos una velada explorando el futuro de NGINX, conectando con la comunidad y disfrutando de dos clásicos: ¡pizza y artículos promocionales! Consulta la página del evento para inscribirte y obtener más información.

¡Esperamos verte el mes que viene en San José!

Sobre el autor

Eric Braun

Más artículos de Eric Braun