El proyecto Envoy Gateway tiene como objetivo llevar a Envoy a las masas - TechCrunch

La Cloud Native Computing Foundation (CNCF) está organizando su conferencia bianual Kubecon+ CloudNativeCon esta semana, por lo que quizás no sea sorprendente que escuchemos algunas noticias sobre proyectos de infraestructura de nube de código abierto en los próximos días. Pero el día antes del evento, el CNCF tiene algunas noticias: está lanzando un nuevo proyecto centrado en Envoy, el popular proxy desarrollado originalmente y de código abierto por Lyft en 2016. El nuevo Envoy Gateway toma el núcleo de Envoy con un modelo de implementación simplificado y una capa API para facilitar que los nuevos usuarios comiencen a usar Envoy como una puerta de enlace API.

Además, CNCF fusiona dos proyectos de puerta de enlace API CNCF existentes, Contour y Emissary, con Envoy Gateway. Ambos proyectos ya han desarrollado funciones de puerta de enlace API para Envoy, pero CNCF argumenta que este nuevo enfoque permitirá que la comunidad converja en torno a un único núcleo de puerta de enlace API con la marca Envoy. El nuevo proyecto, explica la organización en el anuncio de hoy, tiene como objetivo “revite la duplicación de esfuerzos en torno a la seguridad, los tecnicismos del plano de control y otras preocupaciones comunes" y permita a los proveedores centrarse en desarrollar Envoy y este nuevo proyecto en lugar de intentar reinventar la rueda.

La API de Envoy será esencialmente la API de puerta de enlace de Kubernetes con extensiones específicas de Envoy, y el proyecto general tiene como objetivo reducir la complejidad de implementar Envoy como una puerta de enlace de API.

"La desventaja del éxito de Envoy como componente de muchos tipos de arquitectura y soluciones de proveedores diferentes es que es inherentemente de bajo nivel. Envoy no es un software fácil de aprender”, explica CNCF. “Si bien el proyecto ha tenido un gran éxito y ha sido adoptado por las principales empresas de ingeniería de todo el mundo, solo se adopta marginalmente para casos de uso más pequeños y simples en los que nginx y HAProxy siguen siendo dominantes”.