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

Como vicepresidente de productos en NGINX, hablo frecuentemente con clientes y usuarios. Ya sea que pertenezca a un equipo de Platform Ops, un arquitecto de Kubernetes, un desarrollador de aplicaciones, un CISO, un CIO o un CTO, he hablado con alguien como usted. En nuestras conversaciones, me diste tus pensamientos honestos sobre NGINX, incluidos nuestros productos, precios y modelos de licencias, destacando nuestras fortalezas y debilidades.

Lo principal que aprendimos es que nuestro enfoque “NGINX es el centro del universo” no beneficia a nuestros usuarios. Habíamos estado desarrollando productos que apuntaban a hacer de NGINX la “plataforma”: el plano de gestión unificado para todo lo relacionado con la implementación de aplicação . Sabíamos que algunos de nuestros productos anteriores orientados a ese objetivo habían sido poco utilizados y adoptados. Nos dijo que NGINX es un componente crítico para la misión de su plataforma existente, propia o de otro tipo, pero que NGINX no era la plataforma. Por lo tanto, necesitábamos integrarnos mejor con el resto de sus componentes para facilitar la implementación, la gestión y la seguridad de nuestros productos con (y esto es importante) modelos de precios y consumo transparentes. Y todo ello posible mediante API, por supuesto.

El mensaje subyacente era claro: hacer que sea más fácil para usted integrar NGINX en sus flujos de trabajo, cadenas de herramientas existentes y procesos de una manera imparcial. Te escuchamos. En 2024, adoptaremos un enfoque mucho más flexible, simple, repetible y escalable hacia la configuración y gestión de casos de uso para el plano de datos y la seguridad.

Tu deseo tiene todo el sentido. ¡Tu mundo ha cambiado y continúa cambiando! Ha pasado por varias etapas, pasando de configuraciones de nube a híbridas, de multinube y de multinube-híbridas. También hubo cambios de máquinas virtuales a Kubernetes y de API a microservicios y sin servidor. Muchos de ustedes se han desplazado hacia la izquierda y eso ha generado complejidad. Cada vez más equipos tienen más herramientas que requieren mayor gestión, capacidad de observación y seguridad robusta, todo lo cual impulsa aplicaciones que deben poder escalar en minutos, no en horas, días o semanas. Y el último acelerador, la inteligencia artificial (IA), ejerce una presión significativa sobre las arquitecturas de aplicação e infraestructuras heredadas.

Lo que planeamos abordar en los próximos lanzamientos de productos NGINX

Si bien la base de los productos NGINX siempre ha sido sólida, probada en batalla y de alto rendimiento, la forma en que nuestros usuarios podían consumir, administrar y observar todos los aspectos de NGINX no estaba a la altura de los tiempos. Estamos actuando rápidamente para remediarlo con el lanzamiento de un nuevo producto y una serie de nuevas capacidades. Anunciaremos más sobre esto en la conferencia AppWorld 2024 de F5, que tendrá lugar del 6 al 8 de febrero. A continuación se detallan los puntos críticos específicos que planeamos abordar en los próximos lanzamientos de productos.

Punto de dolor n.° 1: Las aplicaciones modernas son difíciles de gestionar debido a la diversidad de entornos de implementación

Hoy en día, los CIO y los CTO pueden elegir entre una amplia variedad de modalidades de implementación de aplicação . Esto es una bendición porque permite muchas más opciones en términos de rendimiento, capacidades y resiliencia. También es una maldición porque la diversidad conduce a la complejidad y la expansión. Por ejemplo, administrar aplicações que se ejecutan en AWS requiere configuraciones, herramientas y conocimientos tribales diferentes a los que requiere administrar aplicações en Azure Cloud.

Si bien los contenedores han estandarizado grandes franjas de implementación de aplicação , todo lo que está debajo de los contenedores (o lo que entra y sale de ellos) sigue estando diferenciado. Como plataforma de orquestación de contenedores de facto, se suponía que Kubernetes limpiaría ese proceso. Pero cualquiera que haya implementado en Amazon EKS, Azure Kubernetes Service (AKS) y Google Kubernetes Engine (GKE) puede decirle que no son para nada iguales.

Usted nos ha dicho que gestionar productos NGINX en esta enorme diversidad de entornos requiere importantes recursos operativos y genera desperdicio. Y, francamente, los modelos de precios basados en licencias anuales colapsan en entornos dinámicos donde puedes lanzar una aplicación en un entorno sin servidor, escalarla en un entorno de Kubernetes y mantener una pequeña implementación interna ejecutándose en la nube para fines de desarrollo.

Punto de dolor n.° 2: Las aplicaciones que se ejecutan en muchos entornos y abarcan distintos tipos de licencias son difíciles de proteger

La complejidad de los diversos entornos puede dificultar el descubrimiento y el monitoreo de dónde se implementan las aplicaciones modernas y luego aplicar las medidas de seguridad adecuadas. Tal vez haya implementado NGINX Plus como su balanceador de carga global y NGINX Open Source para varios microservicios, cada uno ejecutándose en diferentes nubes o sobre diferentes tipos de aplicações. Además, podrían requerir cosas diferentes en cuanto a privacidad, protección de datos y gestión del tráfico.
Cada permutación añade un nuevo giro de seguridad. No existe una solución estándar e integral y eso introduce complejidad operativa y potencial de errores de configuración. Es cierto que hemos aumentado esa complejidad al hacer que resulte confuso qué tipos de seguridad se pueden aplicar a qué soluciones NGINX.

Lo entendemos. Los clientes necesitan una única forma de proteger todas las aplicações que utilizan NGINX. Esta solución de seguridad unificada debe abarcar la gran mayoría de los casos de uso e implementar las mismas herramientas, paneles de control y procesos operativos en todos los entornos, ya sean de 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 NGINX y la visión sin precedentes del tráfico global que tenemos la suerte de tener.

Punto de dolor n.º 3: Gestionar el coste de las aplicaciones modernas es complejo y genera desperdicio

En un mundo centrista, todas las organizaciones quieren capacitar a los desarrolladores y profesionales para que hagan mejor su trabajo, sin necesidad de presentar un ticket ni enviar un mensaje por Slack. La realidad ha sido diferente. Se ha logrado cierta abstracción marginal de la complejidad con Kubernetes, serverless y otros mecanismos para gestionar aplicações distribuidas y aplicações que abarcan entornos locales, de nube y de múltiples nubes. Pero este progreso se ha limitado en gran medida al interior del contenedor y la aplicação. No se ha traducido bien a las capas que rodean las aplicações, como redes, seguridad y observabilidad, ni a CI/CD.

He hecho alusión a estos problemas en los puntos críticos anteriores, pero el resultado final es este: la complejidad tiene grandes costos en términos de horas y trabajo, seguridad comprometida y resiliencia. Mantener sistemas cada vez más complejos es fundamentalmente un desafío y requiere una gran cantidad de recursos. La complejidad de los precios y las licencias añade otra capa de insatisfacción. NGINX nunca ha sido una empresa que “rectifique” y castigue a los usuarios cuando consumen en exceso por error.

Pero en un mundo de SaaS, API y microservicios, lo que se desea es pagar por uso y no por año, ni por puesto o licencia de sitio. Desea un modelo de precios fácil de entender basado en el consumo, para todos los productos y servicios de NGINX, en toda su infraestructura tecnológica y cartera de aplicação . También desea una forma de incorporar soporte y seguridad para cualquier módulo de código abierto que ejecuten sus equipos, pagando solo por las partes que desea.

Esto requerirá algunos cambios en la forma en que NGINX empaqueta y fija el precio de sus productos. La solución definitiva debe ser la simplicidad, la transparencia y el pago por lo que se consume, como cualquier otro SaaS. Te escuchamos. Y tenemos algo grandioso guardado que abordará los tres puntos críticos mencionados anteriormente.

Únase a nosotros en App World 2024

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

Únase a mí en este viaje y sintonice AppWorld para obtener un desglose completo de lo que nos espera. Los precios anticipados están disponibles hasta el 21 de enero. Consulte la página de registro de AppWorld 2024 para obtener más detalles. También estás invitado a unirte a los líderes de NGINX y otros miembros de la comunidad la noche del 6 de febrero en la oficina F5 de San José para una velada en la que miraremos hacia el futuro de NGINX, las conexiones comunitarias y disfrutaremos de los clásicos: pizza y obsequios. Consulte la página del evento para obtener información y detalles.

¡Esperamos verte el próximo mes en San José!