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
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
For example, say your app A makes an HTTP request to app B and app B times out. Ordinarily app A has to build in retry logic (with expontential backoff to avoid dogpiling). Fine if you have a single app, but if you have a dozen microservices, that's a lot of duplicated code.
The solution is to let a proxy handle it for you. Instead of A -> B, you get A -> Envoy -> B. Envoy can do things like retrying, name resolution (something more flexible than DNS that can, say, be used to do A/B tests where traffic to B actually gets routed to another instance of B that runs code from a different branch), load balancing, request/bandwidth throttling, circuit-breaking (failing requests when an overload "trips" the breaker), logging, profiling (measuring timings and making them available to, say, Prometheus), tracing (inserting HTTP headers to generate a path so if a request goes A -> B -> C, then C has a complete "stack trace" that can be used for logging), and so on.
Istio adds a layer of transparency, at least on Kubernetes. Instead of configuring app A to use a proxy, app A just talks to app B as though there's no proxy at all. In reality, Istio has injected some local network magic in the container to route the traffic through the proxy.
But unlike a lot of "web-scale" fads, you can drop this in when you actually do need it, you don't have to worry about it now.
So glance at the istio.com home page, and when/if you need any of that, come back and take a closer look.
Seems like it's the only cats-over-dogs project so far. But not for long ;)
That nets you
$ nix-build -A envoy
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.