4 ms·

Istio was started by Google & IBM, while Envoy was created by Matt Klein at Lyft. One of the reasons why we adopted Envoy at Ambassador for our API Gateway was

by rdli 5y ago

Istio was started by Google & IBM, while Envoy was created by Matt Klein at Lyft. One of the reasons why we adopted Envoy at Ambassador for our API Gateway was precisely because there was no single _commercial_ entity who controlled Envoy. As a note, technically Google & Lyft are VC-funded, so that’s true, although I wouldn’t put Google in the startup category, and Lyft’s business model is unrelated to Envoy.

ThePhysicist 5y ago
I was under the impression that Istio and Envoy are significantly driven by Tetrate (https://www.tetrate.io/ https://www.tetrate.io/), which in my understanding was started by the Istio creators and sells enterprise editions of the two solutions [1]. So yeah it's open source, I can fork it and that's nice, but let's be honest Tetrate aims to monetize these products. Not saying this can't work and be great for the community at the same time, but I'm at least a bit skeptical. 1: https://www.businesswire.com/news/home/20210310005295/en/Tetrate-Started-by-Istio-Founders-Raises-40-Million-to-Help-Enterprises-With-Cloud-Native-Application-Networking-Platform https://www.businesswire.com/news/home/20210310005295/en/Tet...
- bassarid 5y ago
  I've been running Istio for years and have never heard of Tetrate. Tetrate might be started by people who originally worked on Istio, but Istio itself is primarily driven by Google. Istio development is primarily driven by its steering committee [0][1], which is led by Google. If you look at the contributors [2], 6 of the top 10 are Google employees (perhaps more - not everyone lists their employer on GitHub). They have an open design process, posting design documents and similar to their Google Drive [3]. The team is likewise active at community events, where they solicit input that drives what they work on. [0]: https://istio.io/latest/blog/2020/steering-changes/ https://istio.io/latest/blog/2020/steering-changes/ [1]: https://docs.google.com/spreadsheets/d/1Dt-h9s8G7Wyt4r16ZVqcmdWXDuCaPC0kPS21BuAfCL8/edit?usp=sharing https://docs.google.com/spreadsheets/d/1Dt-h9s8G7Wyt4r16ZVqc... [2]: https://github.com/istio/istio/graphs/contributors https://github.com/istio/istio/graphs/contributors [3]: https://istio.io/latest/get-involved/ https://istio.io/latest/get-involved/
- rdli 5y ago
  Envoy was originally written by Matt Klein @ Lyft, and the IP is owned by the Cloud Native Computing Foundation. Here's the initial video where Matt Klein introduces Envoy: https://www.microservices.com/talks/lyfts-envoy-monolith-service-mesh-matt-klein/ https://www.microservices.com/talks/lyfts-envoy-monolith-ser.... If you want to buy commercial support for Envoy & Istio, Tetrate certainly is an option. (Note: I am/was the CEO at Ambassador Labs, which organized the Microservices Practitioner Summit where this talk occurred.)
otterley 5y ago
> One of the reasons why we adopted Envoy at Ambassador for our API Gateway was precisely because there was no single _commercial_ entity who controlled Envoy. I'm a little disappointed that you placed so much weight in that factor. I believe simplicity, reliability, and comprehensive documentation are far more important concerns than whether a commercial entity has control over a project. The flip side of community ownership is more politics, more complexity, bureaucratic decisionmaking, and slower evolution. Connection/service proxies are a dime a dozen. I suspect you could have picked nginx, haproxy, or the Linkerd proxy and been just as well off.
- rdli 5y ago
  > The flip side of community ownership is more politics, more complexity, bureaucratic decisionmaking, and slower evolution. This of course may be true for some communities, but certainly not the case for L7 proxies. In fact, at the time, the opposite was true: NGINX & HAProxy were content in slowly supporting their (captive) customer bases, with little incentive to innovate. This is why Lyft went off to build Envoy Proxy. At GA, it supported features such as HTTP/2, native observability, hitless reloads — none of which were easy / possible to do in NGINX or HAProxy at the time. > Connection/service proxies are a dime a dozen. I suspect you could have picked nginx, haproxy, or the Linkerd proxy and been just as well off. Linkerd proxy didn’t exist then (there was an early version of it, written in Scala IIRC; the Rust version didn’t come along to quite some time later). I agree that there are many options for service proxies. I’ve found, though, that the Envoy community has been pushing innovation in the space quite aggressively.

by rdli 5y ago

ThePhysicist 5y ago

I was under the impression that Istio and Envoy are significantly driven by Tetrate (https://www.tetrate.io/ https://www.tetrate.io/), which in my understanding was started by the Istio creators and sells enterprise editions of the two solutions [1]. So yeah it's open source, I can fork it and that's nice, but let's be honest Tetrate aims to monetize these products. Not saying this can't work and be great for the community at the same time, but I'm at least a bit skeptical. 1: https://www.businesswire.com/news/home/20210310005295/en/Tetrate-Started-by-Istio-Founders-Raises-40-Million-to-Help-Enterprises-With-Cloud-Native-Application-Networking-Platform https://www.businesswire.com/news/home/20210310005295/en/Tet...

bassarid 5y ago
I've been running Istio for years and have never heard of Tetrate. Tetrate might be started by people who originally worked on Istio, but Istio itself is primarily driven by Google. Istio development is primarily driven by its steering committee [0][1], which is led by Google. If you look at the contributors [2], 6 of the top 10 are Google employees (perhaps more - not everyone lists their employer on GitHub). They have an open design process, posting design documents and similar to their Google Drive [3]. The team is likewise active at community events, where they solicit input that drives what they work on. [0]: https://istio.io/latest/blog/2020/steering-changes/ https://istio.io/latest/blog/2020/steering-changes/ [1]: https://docs.google.com/spreadsheets/d/1Dt-h9s8G7Wyt4r16ZVqcmdWXDuCaPC0kPS21BuAfCL8/edit?usp=sharing https://docs.google.com/spreadsheets/d/1Dt-h9s8G7Wyt4r16ZVqc... [2]: https://github.com/istio/istio/graphs/contributors https://github.com/istio/istio/graphs/contributors [3]: https://istio.io/latest/get-involved/ https://istio.io/latest/get-involved/
rdli 5y ago
Envoy was originally written by Matt Klein @ Lyft, and the IP is owned by the Cloud Native Computing Foundation. Here's the initial video where Matt Klein introduces Envoy: https://www.microservices.com/talks/lyfts-envoy-monolith-service-mesh-matt-klein/ https://www.microservices.com/talks/lyfts-envoy-monolith-ser.... If you want to buy commercial support for Envoy & Istio, Tetrate certainly is an option. (Note: I am/was the CEO at Ambassador Labs, which organized the Microservices Practitioner Summit where this talk occurred.)

otterley 5y ago

> One of the reasons why we adopted Envoy at Ambassador for our API Gateway was precisely because there was no single _commercial_ entity who controlled Envoy. I'm a little disappointed that you placed so much weight in that factor. I believe simplicity, reliability, and comprehensive documentation are far more important concerns than whether a commercial entity has control over a project. The flip side of community ownership is more politics, more complexity, bureaucratic decisionmaking, and slower evolution. Connection/service proxies are a dime a dozen. I suspect you could have picked nginx, haproxy, or the Linkerd proxy and been just as well off.

rdli 5y ago
> The flip side of community ownership is more politics, more complexity, bureaucratic decisionmaking, and slower evolution. This of course may be true for some communities, but certainly not the case for L7 proxies. In fact, at the time, the opposite was true: NGINX & HAProxy were content in slowly supporting their (captive) customer bases, with little incentive to innovate. This is why Lyft went off to build Envoy Proxy. At GA, it supported features such as HTTP/2, native observability, hitless reloads — none of which were easy / possible to do in NGINX or HAProxy at the time. > Connection/service proxies are a dime a dozen. I suspect you could have picked nginx, haproxy, or the Linkerd proxy and been just as well off. Linkerd proxy didn’t exist then (there was an early version of it, written in Scala IIRC; the Rust version didn’t come along to quite some time later). I agree that there are many options for service proxies. I’ve found, though, that the Envoy community has been pushing innovation in the space quite aggressively.