Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Envoy: C++ L7 proxy and communication bus

eng.lyft.com

Post reply on HN
Print view View original

21–30 of 33 posts

Re: Announcing Envoy: C++ L7 proxy and communication bus

#21

Post by mattklein123 »

doublerebel wrote: post #19

Wow, with L7 routing on path (not just host) this does almost everything I'm using bud+fabio+consul to do. It's like Hystrix+sidecar-HAProxy in one. The one thing I must have is SNI. The docs only have a short blurb [1], does someone know the full status of SNI support? [1]: https://lyft.github.io/envoy/docs/intro/arch_overview/ssl.ht... EDIT: Also is there any kind of visualization for the resulting network topology…

Visualization is going to be a big area of future investment for us. We already have some pretty cool tools internally and obviously lots of dashboards, etc. but we would love to have a dedicated UI for Envoy. If you know any good UI devs who would want to work on this please send them our way. :)

Re: Announcing Envoy: C++ L7 proxy and communication bus

#22

Post by doublerebel »

mattklein123 wrote: post #21
doublerebel wrote: post #19

Wow, with L7 routing on path (not just host) this does almost everything I'm using bud+fabio+consul to do. It's like Hystrix+sidecar-HAProxy in one. The one thing I must have is SNI. The docs only have a short blurb [1], does someone know the full status of SNI support? [1]: https://lyft.github.io/envoy/docs/intro/arch_overview/ssl.ht... EDIT: Also is there any kind of visualization for the resulting network topology…

Visualization is going to be a big area of future investment for us. We already have some pretty cool tools internally and obviously lots of dashboards, etc. but we would love to have a dedicated UI for Envoy. If you know any good UI devs who would want to work on this please send them our way. :)

Thanks for all the info. Any insight into the service discovery issues described in the docs [1]?

  Many existing RPC systems treat service discovery as a
  fully consistent process. To this end, they use fully
  consistent leader election backing stores such as
  Zookeeper, etcd, Consul, etc. Our experience has been
  that operating these backing stores at scale is painful.
[1]: https://lyft.github.io/envoy/docs/intro/arch_overview/servic...

Re: Announcing Envoy: C++ L7 proxy and communication bus

#23

Post by mattklein123 »

doublerebel wrote: post #22
mattklein123 wrote: post #21

Earlier quoted context omitted.

Visualization is going to be a big area of future investment for us. We already have some pretty cool tools internally and obviously lots of dashboards, etc. but we would love to have a dedicated UI for Envoy. If you know any good UI devs who would want to work on this please send them our way. :)

Thanks for all the info. Any insight into the service discovery issues described in the docs [1]? Many existing RPC systems treat service discovery as a fully consistent process. To this end, they use fully consistent leader election backing stores such as Zookeeper, etcd, Consul, etc. Our experience has been that operating these backing stores at scale is painful. [1]: https://lyft.github.io/envoy/docs/intro/arch_ov…

Mainly just years of experience at different companies watching ZK, etcd, etc. fall over at scale and require teams of people to maintain them.

We have had zero outages caused by our eventually consistent discovery system with active health checking (knock on wood), and haven't really touched the discovery service code in months. It just runs.

I'm not saying that a system using ZK, etc. can't be made to work. It certainly can since many companies do it. It's mostly that I think those solutions are actually making the overall problem a lot more complicated and prone to failure than it has to be.

Re: Announcing Envoy: C++ L7 proxy and communication bus

#25

Post by wyager »

_RPM wrote: post #24

> Envoy works with any application language. A single Envoy > deployment can form a mesh between Java, C++, Go, PHP, > Python, etc. I find it odd that they did not include Rust in their list of preferred languages. Rust is safer than C++ and Go.

Lots of things are safer than C++ and Go. Many just don't see as much use.

Re: Announcing Envoy: C++ L7 proxy and communication bus

#26

Post by conradev »

_RPM wrote: post #24

> Envoy works with any application language. A single Envoy > deployment can form a mesh between Java, C++, Go, PHP, > Python, etc. I find it odd that they did not include Rust in their list of preferred languages. Rust is safer than C++ and Go.

I assume that's list of languages that are commonly used to host web services or power databases.

Re: Announcing Envoy: C++ L7 proxy and communication bus

#27

Post by blub »

_RPM wrote: post #24

> Envoy works with any application language. A single Envoy > deployment can form a mesh between Java, C++, Go, PHP, > Python, etc. I find it odd that they did not include Rust in their list of preferred languages. Rust is safer than C++ and Go.

Rust barely registers outside HN and a few other web gathering places.

All those other languages have their niches and ecosystems and are safe enough.

Re: Announcing Envoy: C++ L7 proxy and communication bus

#28

Post by twic »

_RPM wrote: post #24

> Envoy works with any application language. A single Envoy > deployment can form a mesh between Java, C++, Go, PHP, > Python, etc. I find it odd that they did not include Rust in their list of preferred languages. Rust is safer than C++ and Go.

The thing that struck me about language choice was the list of also-rans:

> very productive but not particularly well performing languages such as PHP, Python, Ruby, Scala, etc

Which seems to be missing a certain more-productive-than-C++ and very well-performing coffee-themed language.

I mean, you would never use Java for this, because although it could go fast enough, it would need way too much memory to do it. But i would have liked to see it dismissed for that reason rather than glossed over!

Re: Announcing Envoy: C++ L7 proxy and communication bus

#29

Post by Retra »

mgrennan wrote: post #18

Just seems like another piece of code in search of a problem and ways for things to go wrong, because someone didn't take to time to research how things work now.

Do you have any relevant criticisms, or are we all supposed to just pretend we already know what your problem is?

Re: Announcing Envoy: C++ L7 proxy and communication bus

#30

Post by ryan_lane »

halayli wrote: post #16

Wouldn't this require private keys to be sprinkled on all machines running it to inspect the traffic?

I work for Lyft.

For this we have a secret management system, called confidant (https://lyft.github.io/confidant/), that we use to distribute any necessary secrets. So, yes, you may need to have keys on every node (depending on your monitoring system), but assuming you securely distribute them, it's not a big deal.

This is, of course, a general problem that's not necessarily related to envoy.

Post reply on HN