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.
Envoy: 7 months later
31–40 of 48 posts
Re: Envoy: 7 months later
#32Earlier 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?
Re: Envoy: 7 months later
#33Earlier 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?
Re: Envoy: 7 months later
#34Re: Envoy: 7 months later
#35Re: Envoy: 7 months later
#36Interesting 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.
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
#37Re: Envoy: 7 months later
#38I wonder why they chose C++ and not Go.
Re: Envoy: 7 months later
#39Looks 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...
Re: Envoy: 7 months later
#40Looks 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...
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.