La fiebre de las mallas de servicios: elegir entre Aspen Mesh y NGINX

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Junto con el ecosistema de contenedores en general, las mallas de servicios siguen avanzando hacia la madurez. Sin embargo, aún estamos en una fase inicial y se están aplicando diversos enfoques para resolver el problema de la gestión del tráfico entre contenedores mediante mallas de servicios.

Nosotros (y con «nosotros» me refiero a la empresa) respondimos a muchas preguntas en los meses previos a la adquisición oficial de NGINX esta primavera. Varias de ellas se centraban en áreas de «solapamiento» tecnológico y de soluciones. Al fin y al cabo, tanto NGINX como F5 ofrecen soluciones de entrega de aplicaciones basadas en proxies. Tanto NGINX como F5 están desarrollando una malla de servicios. La pregunta era: ¿cuál de las dos se impondría?

Porque así es como suelen funcionar las adquisiciones.

Como reiteramos a menudo mi homólogo de NGINX y yo, las tecnologías que se señalaban como solapadas eran, a nuestro juicio, más complementarias que competidoras. Lo mismo ocurre con nuestras soluciones de malla de servicios.

Nuestro razonamiento parte de una visión compartida de la entrega de aplicaciones. Ambos somos conscientes del impacto que los contenedores y la nube, los microservicios y la proliferación de brechas de seguridad están teniendo en las arquitecturas y los modelos de entrega de aplicaciones. Del mismo modo que ya no existe «una única ruta de datos para entregar todas las aplicaciones», tampoco existe «un único modelo de entrega de aplicaciones para proporcionar todos los servicios de aplicaciones». La nube introduce múltiples rutas de datos. Los contenedores introducen una nueva ruta de datos. Ambos amplían las posibles ubicaciones de los servicios de aplicaciones, que pasan de un proxy basado en la red (un ADC) a una larga lista de ubicaciones que abarca desde el cliente hasta la nube, pasando por la red, el servidor y el contenedor.

Como señalamos en una publicación centrada en las arquitecturas de nuestra serie Bridging the Divide, la elección de dónde y cómo se prestan los servicios de aplicaciones depende de muchos factores. No se trata simplemente de elegir entre implementaciones de distintos proveedores o entre «soluciones empresariales y software libre y de código abierto»; es una decisión que debe tener en cuenta la ubicación (en la nube o en las instalaciones), el modelo operativo e incluso la facilidad de implementación frente a la funcionalidad necesaria. Dada la amplitud de la ruta de entrega, existen múltiples opciones para incorporar servicios de aplicaciones.

Por eso consideramos que nuestra cartera combinada de F5 y NGINX es complementaria, no competitiva. El motivo es que, en el mercado global de la entrega de aplicaciones, ya no se compite por estar presente en una única ubicación, sino en varias.

Las mallas de servicios están diseñadas para escalar y proteger los entornos de contenedores, así como para proporcionar visibilidad sobre ellos. Al tratarse de una tecnología incipiente y en rápida evolución, están surgiendo varios modelos. Uno se basa en el uso de un proxy sidecar (Envoy se ha consolidado como uno de los principales proyectos de CNCF y como el proxy sidecar estándar del sector), mientras que el otro aprovecha los proxies por aplicación, al estilo de NGINX Plus.

Actualmente tenemos previsto ofrecer compatibilidad con ambas opciones, ya que los clientes tienen opiniones muy firmes sobre sus elecciones de infraestructura en lo que respecta a los contenedores. Algunos prefieren Istio y Envoy, mientras que otros han estandarizado toda su infraestructura en torno a NGINX.

La cantidad de componentes que deben operarse y gestionarse en un entorno de contenedores hace que la experiencia tecnológica existente sea un factor importante a la hora de elegir una malla de servicios. Las organizaciones que han estandarizado su infraestructura en torno a NGINX tenderán de forma natural a optar por una solución de malla de servicios de NGINX, ya que está compuesta íntegramente por software de NGINX, desde el proxy NGINX o NGINX Unit hasta NGINX Controller. La experiencia operativa existente con NGINX y su ecosistema de código abierto puede reducir las dificultades y los retrasos en la implementación.

Otras organizaciones comparten esta visión respecto a soluciones alternativas de código abierto como Istio y Envoy. Aspen Mesh utiliza Envoy y se implementa sobre Istio, por lo que resulta una opción más natural para las organizaciones que ya han invertido en la tecnología subyacente. Se trata de una distribución de Istio probada, reforzada, empaquetada y validada. Aspen Mesh añade varias funciones a Istio, entre ellas una experiencia de usuario más sencilla mediante el panel de Aspen Mesh, un marco de políticas que permite a los usuarios definir, medir y aplicar objetivos empresariales, y herramientas como Istio Vet y Traffic Claim Enforcer. Aspen Mesh, al igual que NGINX, también se integra perfectamente con F5 BIG-IP.

Tanto NGINX como Aspen Mesh ofrecen funciones de gestión y visualización de clústeres de Kubernetes. Tanto Aspen Mesh como NGINX ofrecen su solución como opción para instalaciones locales. Ambos proporcionan funciones de rastreo y métricas que son fundamentales para abordar el problema de la visibilidad, uno de los principales retos en los entornos de producción, señalado por el 37 % de las organizaciones en el informe sobre el estado de Kubernetes de Replex.

Las organizaciones que prefieran un enfoque de malla de servicios basado en proxies sidecar se decantarán por Aspen Mesh. Las organizaciones que consideren que las mallas de servicios basadas en un proxy por aplicación se adaptan mejor a sus necesidades preferirán NGINX.

Su elección depende de diversos factores, y creemos que este ámbito emergente es lo bastante importante como para seguir ofreciendo opciones que respondan a distintas combinaciones de necesidades y requisitos.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie