
Envoy: 7 months later - mattklein123
https://eng.lyft.com/envoy-7-months-later-41986c2fd443
======
tedd4u
There was a very interesting talk at Google Next in March that described a way
in which the Kubernetes open source team is bringing this sidecar architecture
to Kub. In fact I think they are working with the Lyft team. The whole talk is
interesting but I've added a time offset to skip to the bit where they talk
about sidecar/service mesh.

[https://www.youtube.com/watch?v=3quCoi5YHz4#t=27m59s](https://www.youtube.com/watch?v=3quCoi5YHz4#t=27m59s)

Also, there is [https://istio.io/](https://istio.io/) but it's a placeholder
site at the moment.

~~~
aledbf
You can find the project here
[https://github.com/istio/manager](https://github.com/istio/manager)

------
shawabawa3
Looks interesting except imo the configuration makes it basically unusable.

They use jinja2 templated json... and there are hundreds of lines for their
"simple" examples.

Even the "hello world" type example of proxying to google is a mess
[https://github.com/lyft/envoy/blob/master/configs/google_com...](https://github.com/lyft/envoy/blob/master/configs/google_com_proxy.json)

~~~
henrikschroder
I love how history repeats itself.

I remember everyone complaining about Spring and similar having these massive
XML configuration files, and then people said "never again!", and moved to
very simple JSON formats for their frameworks. And then everyone adds a little
bit to the best practices, and over time we get this, again.

~~~
stickfigure
Seriously. How about we just call it EJB 4.0?

~~~
shouldbworking
JSON Server Faces™

------
josephjacks
Envoy is an extremely exciting project. I've been following it closely since
OSS inception and am thrilled to see the upcoming deep integration with the
Kubernetes project. Such a natural and complimentary fit!

With flexibility as both a side car and host proxy network call fabric for
polyglot distributed services, I see Envoy as a kind of modern ESB for the
reincarnation of SOA we are seeing in the microservices movement. Congrats to
the awesome contributors from Lyft/IBM/Google and others!

------
moondev
Interesting that it seems like there is a bunch of overlap with linkerd in the
k8s space. With both k8s and linkerd being CNCF projects, I wonder why google
is putting so many resources behind envoy rather than linkerd. I guess that's
the beauty of the k8s ecosystem though, freedom and choice to use what you see
fit. K8s just provides the rock-solid primitives.

~~~
politician
linkerd has a dependency on the JVM, k8s doesn't, and not everyone wants to
pull in the JVM if they're not already using it.

~~~
Spiritus
I guess that's one the reasons they created
[https://github.com/linkerd/linkerd-tcp](https://github.com/linkerd/linkerd-
tcp)

------
TheDong
Are envoy and linkerd comparable? They look like they fill similar niches, but
I'm not familiar enough to know what I don't know.

~~~
sandGorgon
This. Linkerd has been a pretty cool piece of tech. In fact, their rewrite
linkerd-tcp is in Rust and is blazingly fast. Also, it works on L4 and can do
more stuff than Envoy... though I think that advantage is going to be
shortlived.

Linkerd guys have been focusing on building deep integration with k8s (as an
ingress or sidecar), but this announcement of Envoy trumps it all.

> _" We are excited to announce that we are working in partnership with both
> Google and IBM to bring Envoy to Kubernetes. Fun fact: there are now more
> people working on Envoy at Google than there are at Lyft! We have a lot of
> other things planned with Google that we will be able to share more about in
> the coming months."_

That's a bummer for the amazing guys at Buoyant. I had hoped for linkerd to be
the next generation of ingress in k8s.

Envoy is in C++, while linkerd-tcp is in Rust. I wonder how much role did the
choice of tooling play in Google's decision to adopt.

~~~
gtirloni
Isn't linkerd in Scala and linkerd-tcp a small subset of it?

~~~
politician
That's correct. linkerd/namerd run on the JVM.

------
rdli
We've been experimenting with Envoy for a few months and have been really
impressed with the technology and the responsiveness of the community. We're
actually deploying an API Gateway built on Envoy so you can easily extend your
service mesh all the way out to the edge. Planning on open sourcing it soon
(if anyone wants to give it a try, my email is in my profile).

~~~
lunch
Any reason you chose to use API Gateway for your edge instead of another Envoy
with an ELB in front?

~~~
rdli
Sorry, I wasn't clear. I was referring to using Envoy as an API gateway, not a
specific API gateway product. We had to write some wrapper code on top of
Envoy that lets you use a REST API to map URLs to services running in your
Kube cluster and then dynamically update Envoy config, etc.

------
msoad
For Googlers out there: Envoy is basically GFE

~~~
curiousDog
Wut? More like Kubernetes is like Borg.

~~~
msoad
Sorry mixed up. Yes, GFE is more accurate

------
perfmode
I wonder why they chose C++ and not Go.

~~~
olalonde
I presume because the author was more familiar and experienced with C++.

------
searchfaster
Any numbers on latency Envoy adds for each request ?

~~~
eggie5
according to the talk I just watched, latency/performance was their concern
coming out of the gate and was the impetus for writing it in C++...

~~~
searchfaster
Thanks.. just tried it out with my service, beats nginx for simple http
proxying pretty easily by a nice margin. Envoy supports way more features than
nginx too !

------
rajesht
An engineering blog without any diagrams?

