Envoy vs Istio: What are the differences?
Developers describe Envoy as "C++ front/service proxy". Originally built at Lyft, Envoy is a high performance C++ distributed proxy designed for single services and applications, as well as a communication bus and “universal data plane” designed for large microservice “service mesh” architectures. On the other hand, Istio is detailed as "Open platform to connect, manage, and secure microservices, by Google, IBM, and Lyft". Istio is an open platform for providing a uniform way to integrate microservices, manage traffic flow across microservices, enforce policies and aggregate telemetry data. Istio's control plane provides an abstraction layer over the underlying cluster management platform, such as Kubernetes, Mesos, etc.
Envoy can be classified as a tool in the "Load Balancer / Reverse Proxy" category, while Istio is grouped under "Microservices Tools".
Envoy and Istio are both open source tools. It seems that Istio with 18.5K GitHub stars and 3.1K forks on GitHub has more adoption than Envoy with 10.2K GitHub stars and 1.58K GitHub forks.
Cuemby, Entelo, and AgFlow are some of the popular companies that use Istio, whereas Envoy is used by Handshake, VSCO, and CommonBond. Istio has a broader approval, being mentioned in 32 company stacks & 30 developers stacks; compared to Envoy, which is listed in 18 company stacks and 14 developer stacks.
Envoy proxy is widely adopted in many companies for service mesh proxy, but it utilizes BoringSSL by default. Red Hat OpenShift fork envoy branch with their own OpenSSL support, I wonder any other companies are also using envoy-openssl branch for compatibility? How about AWS App Mesh?
Any input would be much appreciated!
Istio based on powerful Envoy whereas Kong based on Nginx. Istio is K8S native as well it's actively developed when k8s was successfully accepted with production-ready apps whereas Kong slowly migrated to start leveraging K8s. Istio has an inbuilt turn-keyIstio based on powerful Envoy whereas Kong based on Nginx. Istio is K8S native as well it's actively developed when k8s was successfully accepted with production-ready apps whereas Kong slowly migrated to start leveraging K8s. Istio has an inbuilt turn key solution with Rancher whereas Kong completely lacks here. Traffic distribution in Istio can be done via canary, a/b, shadowing, HTTP headers, ACL, whitelist whereas in Kong it's limited to canary, ACL, blue-green, proxy caching. Istio has amazing community support which is visible via Github stars or releases when comparing both.