The Istio home page probably does a better job of explaining "why?" than the envoy home page; the envoy home page is better at explaining "what?".
why both Envoy and Linkerd are on their page as service mesh
Linkerd is written in Scala. There are a class of people who avoid the JVM, sometimes for good reasons. For one, Envoy is more resource-efficient. See https://github.com/envoyproxy/envoy/issues/99.Envoy is a self contained process that is designed to run alongside every application server. All of the Envoys form a transparent communication mesh in which each application sends and receives messages to and from localhost and is unaware of the network topology.
and
Although Envoy is primarily designed as a service to service communication system, there is benefit in using the same software at the edge (observability, management, identical service discovery and load balancing algorithms, etc.). Envoy includes enough features to make it usable as an edge proxy for most modern web application use cases.
both from https://envoyproxy.github.io/envoy/intro/what_is_envoy.html
Seems like it's the only cats-over-dogs project so far. But not for long ;)
That nets you
$ nix-build -A envoy
... and then you're done. Of course, we have a CI server that builds our packages regularly, so it's likely you wouldn't even need to build from source (though you certainly could, if desired).If I wanted to run a Python app, which serves gRPC, what would be the easiest path?
I currently use nghttp2 for gRPC proxy/routing
What seems particularly offensive to me is that it declares that it specifically requires GCC 4.9. I'm really not OK pinning your brand new impressive world changing open source cloud technology to a compiler release series that's 3.5 years old. It looks either staid, or uncaring, or otherwise dull to have slipped to far behind the times, and it's intimidating to think the codebase is complex enough C or C++ that it really matters a whole lot.