Service Mesh Mania: elegir Aspen Mesh o NGINX
Junto con el ecosistema de contenedores más amplio, las mallas de servicios siguen avanzando hacia su madurez. Sin embargo, aún estamos en las primeras etapas y se están aplicando diversos enfoques para resolver el problema de la gestión del tráfico dentro de los contenedores con mallas de servicios.
Nosotros (el nosotros corporativo) respondimos muchas preguntas antes de nuestra adquisición oficial de NGINX esta primavera. Varios de ellos se centraron en áreas de “superposición” en tecnología y soluciones. Después de todo, tanto NGINX como F5 ofrecen soluciones de entrega de aplicação basadas en proxy. Tanto NGINX como F5 están construyendo una malla de servicios. La pregunta era ¿quién ganaría?
Porque así es como suelen funcionar las adquisiciones.
Como mi homólogo de NGINX y yo reiteramos a menudo, las tecnologías señaladas como superpuestas eran, en nuestra opinión, más complementarias que competitivas. Esto también se aplica a nuestras soluciones de malla de servicios.
Nuestra lógica se deriva de una visión compartida de la entrega de aplicação . Ambos vemos el impacto que los contenedores, la nube, los microservicios y una preponderancia de violaciones de seguridad están teniendo en las arquitecturas y los modelos de entrega de aplicação . De la misma manera que ya no existe "una única ruta de datos para entregar todas las aplicações", ya no existe "un único modelo de entrega de aplicação para entregar todos los servicios de aplicação ". La nube introduce múltiples rutas de datos. Los contenedores introducen una nueva ruta de datos. Ambos amplían la posible ubicación de los servicios de aplicação desde un proxy basado en red (un ADC) a una larga lista de ubicaciones que van desde el cliente a la red, al servidor, al contenedor y a la nube.
Como señalamos en una publicación centrada en las arquitecturas en nuestra serie Bridging the Divide , la elección de dónde y cómo uno entrega servicios de aplicação depende de muchos factores. No se trata simplemente de una elección entre implementaciones de proveedores o "empresa versus FOSS"; es una elección que debe tener en cuenta la ubicación (nube o local), el modelo operativo e incluso la facilidad de implementación frente a la funcionalidad requerida. Considerando la amplitud de la ruta de entrega, esto proporciona múltiples opciones para insertar servicios de aplicação .
Es por esto que consideramos que nuestras carteras combinadas de F5 y NGINX son complementarias y no competitivas. Porque el mercado general de distribución de aplicação ya no compite por la ubicación en una única ubicación, sino que compite por la ubicación en múltiples ubicaciones.
Las mallas de servicio están diseñadas para escalar, proteger y brindar visibilidad en entornos de contenedores. Al ser una tecnología naciente y en rápida evolución, están surgiendo múltiples modelos. Uno se basa en el uso de un proxy sidecar ( Envoy ha surgido como un proyecto CNCF líder y el proxy sidecar estándar de la industria) y el otro aprovecha los proxies por aplicación, como NGINX Plus .
Actualmente planeamos brindar soporte a ambos porque los clientes tienen opiniones muy firmes sobre sus opciones de infraestructura cuando se trata de contenedores. Algunos prefieren Istio y Envoy y otros están estandarizados en todo NGINX.
La cantidad de componentes que deben operarse y administrarse en un entorno de contenedores es tal que la experiencia existente en tecnología es un factor importante a la hora de elegir una malla de servicios. Es natural que las organizaciones que han estandarizado NGINX para su infraestructura se inclinen por una solución de malla de servicios NGINX porque comprende todo el software NGINX, desde el proxy NGINX o la unidad NGINX hasta el controlador NGINX. La experiencia operativa existente en NGINX y su ecosistema de código abierto puede significar menos fricción y demoras en la implementación.
Otras organizaciones tienen las mismas opiniones sobre soluciones alternativas de código abierto como Istio y Envoy. Aspen Mesh utiliza Envoy y se implementa sobre Istio, por lo que es una opción más natural para organizaciones con inversiones existentes en la tecnología subyacente. Es una distribución de Istio probada, reforzada, empaquetada y examinada. Aspen Mesh agrega varias características a Istio que incluyen una experiencia de usuario más simple a través del panel de Aspen Mesh, un marco de políticas que permite a los usuarios especificar, medir y aplicar objetivos comerciales y herramientas como Istio Vet y Traffic Claim Enforcer . Aspen Mesh, como NGINX, también se integra bien con F5 BIG-IP.
Tanto NGINX como Aspen Mesh ofrecen gestión y visualización de clústeres de Kubernetes. Tanto Aspen Mesh como NGINX ofrecen su solución como una opción local. Ambos brindan seguimiento y métricas que son fundamentales para abordar el problema de la visibilidad, uno de los principales desafíos de producción señalado por el 37 % de las organizaciones en el Informe sobre el estado de Kubernetes de Replex .
Las organizaciones que prefieren un enfoque basado en proxy sidecar para la malla de servicios preferirán Aspen Mesh. Las organizaciones que creen que las mallas de servicios basadas en proxy por aplicación se adaptan mejor a sus necesidades preferirán NGINX.
Su elección depende de una variedad de factores y creemos que este espacio emergente es lo suficientemente importante como para seguir apoyando opciones que aborden diferentes combinaciones de necesidades y requisitos.