Le projet Envoy Gateway veut amener Envoy au plus grand nombre

La Cloud Native Computing Foundation (CNCF) organise cette semaine sa conférence semi-annuelle Kubecon+ CloudNativeCon, il n’est donc peut-être pas surprenant que nous entendions pas mal de nouvelles sur les projets d’infrastructure cloud open source dans les prochains jours. Mais même un jour avant l’événement, la CNCF a une petite nouvelle : elle lance un nouveau projet construit autour d’Envoy, le populaire proxy développé à l’origine et open-source par Lyft en 2016. Le nouveau Envoy Gateway reprend le cœur d’Envoy avec un modèle de déploiement et couche API simplifiés pour permettre aux nouveaux utilisateurs de démarrer plus facilement avec Envoy en tant que passerelle API.

En outre, la CNCF fusionne également deux projets de passerelle API CNCF existants, Contour et Emissary, avec Envoy Gateway. Ces deux projets développaient déjà des fonctionnalités de passerelle API pour Envoy, mais la CNCF affirme que cette nouvelle approche permettra à la communauté de converger autour d’un seul noyau de passerelle API de marque Envoy. Le nouveau projet, explique l’organisation dans l’annonce d’aujourd’hui, est destiné à « réduquer les efforts redondants autour de la sécurité, contrôler les détails techniques du plan et d’autres préoccupations partagées » et permettre aux fournisseurs de se concentrer sur la construction d’Envoy et de ce nouveau projet au lieu d’essayer de réinventer la roue.

L’API Envoy sera essentiellement l’API de la passerelle Kubernetes avec des extensions spécifiques à Envoy et le projet global vise à réduire la complexité du déploiement d’Envoy en tant que passerelle API.

« Le revers de la médaille du succès d’Envoy en tant que composant de nombreux types d’architecture et de solutions de fournisseurs différents est qu’il est intrinsèquement de bas niveau ; Envoy n’est pas un logiciel facile à prendre en main », explique la CNCF. « Bien que le projet ait eu un énorme succès en étant adopté par de grandes organisations d’ingénierie du monde entier, il n’est que légèrement adopté pour des cas d’utilisation plus petits et plus simples, où nginx et HAProxy sont toujours dominants.

Source-146