Live data from Hacker News

Envoy: 7 months later

eng.lyft.com

31–40 of 48 posts

Re: Envoy: 7 months later

#31

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...

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.

Seriously. How about we just call it EJB 4.0?

Re: Envoy: 7 months later

#32

Earlier quoted context omitted.

Seems like they could have used something a bit nicer to work with too (yaml, libucl, hocon, etc). I am honestly getting tired of editing fiddly json (no comments, last element in list can't have a comma, etc) all over the place.

Given Google's involvement, I am wondering why they did not choose jsonnet?

Hopefully, it was avoided on purpose because it's a complete nightmare to use.

Re: Envoy: 7 months later

#33

Earlier quoted context omitted.

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.

Seriously. How about we just call it EJB 4.0?

JSON Server Faces™

Re: Envoy: 7 months later

#35

Earlier quoted context omitted.

Given Google's involvement, I am wondering why they did not choose jsonnet?

Hopefully, it was avoided on purpose because it's a complete nightmare to use.

Honest question: How so?

I have not used it in anger - just played around with it.

Re: Envoy: 7 months later

#36
post #16

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.

One downside to using Linkerd is that unless you have very few apps — or an overabundance of RAM — you can't realistically deploy it as a "sidecar container". The JVM consumes about 100MB of RAM, by their account; it's not lightweight.

The sidecar pattern (used by Envoy and by Google's new project, istio) is desirable in that it compartmentalizes the rules and logic in the pod that uses them, as opposed to sharing all settings across all apps. Zero dependencies (between pods) is a great way to manage complexity. I haven't thought much about it, but there might be latency benefits, too.

Re: Envoy: 7 months later

#39

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...

That's how they use it, that's not how you have to choose to use it. It is one of the most tedious aspects of the tool but all the different aspects exist for a reason, there just needs to be an easy mode for people starting off.

Re: Envoy: 7 months later

#40

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...

This is a battle that repeats itself ever so often. Same deal with kubernetes config files.

It's the same opinionated positions of puppet vs chef/ansible. Building the tooling in the form of an embedded programming language (lua for nginx, python for ansible) is so much better.

But that is a much more polarising position to take. It's politically untenable. Ruby engineers will say no to python and vice versa... So you start arriving at Json or XML based configurations which are a programmatic neutral ground.

IMHO lua-jit occupies the same political neutrality as XML.

Post reply on HN