Si vous travaillez dans le domaine de l’IT depuis un moment, ou si vous avez simplement pris le temps de regarder ce qui se passe derrière le rideau des applications modernes, vous avez sûrement déjà entendu parler de HAProxy, Nginx ou même Apache.
Ces applications sont des proxies (ou reverse proxies pour être plus précis). Ils ont été créés initialement pour gérer le trafic nord-sud, c’est-à-dire le trafic qui entre et sort d’un datacenter ou d’une infrastructure vers l’extérieur.
Ce genre d’application fonctionne très bien pour ces usages classiques. Cependant, avec les nouvelles méthodes de développement, notamment l’avènement du SOA (Service Oriented Architecture) puis des microservices, ces proxies ont vite montré leurs limites.
Les géants du cloud comme Google, Lyft ou Amazon ont identifié 3 problèmes que les proxies classiques peinaient à résoudre :
- Le trafic est désormais majoritairement est-ouest (entre services) plutôt que nord-sud.
- L’observabilité et la télémétrie sont devenues critiques pour gérer la complexité des architectures distribuées.
- La gestion des configurations et des déploiements doit être dynamique et automatisable.
“À l’ancienne”, à chaque modification d’une règle de routage ou ajout d’un service, il fallait modifier la configuration du proxy manuellement et redémarrer le service. Cela provoquait des interruptions et augmentait le risque d’erreurs humaines.
De plus, puisque la majorité du trafic se fait désormais entre services, les standards de sécurité actuels (Zero Trust) exigent que chaque service puisse vérifier l’identité de son interlocuteur et que le trafic soit chiffré de bout en bout. Cela générait une complexité énorme pour les développeurs, qui devaient inclure toute cette logique de sécurité et de réseau directement dans le code métier.
C’est dans ce contexte qu’Envoy a été créé par Lyft en 2016. C’est un proxy open-source conçu spécifiquement pour répondre aux besoins de ces architectures modernes.
Envoy, c’est quoi ?
Envoy est littéralement utilisé par les géants de la tech (Google, Amazon, Microsoft, IBM). On le retrouve partout : dans les architectures microservices, les Service Meshes (Istio, Consul Connect), les CDN, les API Gateways et même au cœur des infrastructures de cloud public.
En bref, Envoy est un proxy L7 (couche applicative) qui fonctionne généralement comme un sidecar ou une gateway. Il est conçu pour être hautement performant (codé en C++), extensible (via des filtres) et configurable dynamiquement (via xDS APIs).
Les concepts clés
Configuration dynamique
Le gros atout d’Envoy, c’est sa capacité à mettre à jour sa configuration sans redémarrage (hot reload). Via les APIs xDS (Listener, Route, Cluster, Endpoint Discovery Services), un control plane comme Istio ou Consul peut pousser de nouvelles règles de routage à des milliers d’instances Envoy en quelques secondes.
Plus besoin de SSH sur vos machines pour modifier des fichiers de config. Tout est centralisé et automatisé.
Le pattern Sidecar
Envoy tourne généralement en tant que sidecar, c’est-à-dire dans un conteneur accolé à votre application (dans le même Pod Kubernetes par exemple). Votre code applicatif ne gère plus la logique réseau complexe, il fait juste une requête vers http://localhost:15001/api/users et Envoy s’occupe du reste : load balancing, retries, circuit breaking, TLS, métriques…
Cette séparation des responsabilités (separation of concerns) est géniale car elle permet d’être agnostique du langage. Python, Go, Java, Rust… tout le monde bénéficie de la même infrastructure réseau sans réimplémenter les bibliothèques.
Observabilité native
Envoy collecte automatiquement des métriques détaillées sur chaque requête : latence (p50, p95, p99), codes HTTP, erreurs, timeouts. Tout ça sans écrire une seule ligne de code dans votre app. Ces métriques sont directement exploitables dans Prometheus et Grafana.
Note : Si vous ne savez pas ce que sont les p50, p95, p99, je vous conseille cet article.
C’est un gain de temps énorme. Auparavant, il fallait instrumenter chaque service manuellement. Maintenant, vous avez une vue unifiée de toute votre infrastructure.
Sécurité “by design”
Envoy gère nativement le TLS et le mTLS (mutual TLS). Chaque service peut vérifier l’identité de l’autre avant d’accepter une connexion, et le trafic est chiffré. Dans un monde où le Zero Trust devient la norme, c’est un avantage considérable qui décharge les développeurs.
Des applications réelles
Pour l’anecdote, Lyft (qui a créé l’outil) l’utilise pour gérer des millions de requêtes par seconde entre ses microservices. Résultat : une réduction de latence de 20% et une disponibilité augmentée à 99.999%.
De même, Google Cloud Platform utilise Envoy par défaut pour ses Load Balancers HTTP(S). Si vous êtes sur GCP, vous utilisez déjà Envoy sans le savoir. Istio, le Service Mesh le plus populaire, l’utilise également comme data plane.
Envoy est omniprésent.
Mais pas de magie non plus
Envoy résout beaucoup de problèmes, mais il en crée aussi de nouveaux.
- Courbe d’apprentissage : Elle est raide.
- Configuration : Le YAML peut vite devenir monstrueux et difficile à débugger.
- Latence : Vous ajoutez forcément un saut réseau (5-10ms de latence ajoutée, voire plus selon la config).
- Complexité opérationnelle : C’est un composant de plus à maintenir.
Mon expérience m’a appris qu’Envoy n’est pas fait pour tout le monde. Si vous avez 5 services qui tournent tranquillement avec Nginx, pas besoin de tout casser pour migrer. Mais si vous construisez une architecture distribuée avec 50+ microservices, Envoy (ou un service mesh basé dessus) devient quasi indispensable.
Comme toujours, le contexte est roi.
Ce qui vient ensuite
Cet article n’est qu’une introduction. Dans les prochains posts, nous plongerons dans :
- La configuration concrète d’Envoy (listeners, routes, clusters)
- Les patterns avancés (canary deployments, A/B testing, fault injection)
- L’intégration avec Kubernetes
- Les performances et le tuning en production
Envoy est un outil complexe mais puissant. Nous prendrons le temps de l’apprivoiser progressivement.