humzashah / envoy-demo Goto Github PK

Heya,

Looking at the simple use cases provided in the README I'm a little concerned that this PoC and later applications being deployed using this pattern may be oversharing, or otherwise, have undesirable effects.

a) automatically providing a /health endpoint. I don't think that a sidecar should be responsible for determining the health of a service. That's logic that only the true application process can know.

b) Should the /info and envoy's http port be available to the public?

c) Should the container manger be exposing port 5000 in this example? (A direct connection to the application, not envoy).
This puts envoy as an incoming proxy.
- pro: For http traffic, envoy can protect the appliation server from slowloris attacks (does envoy actaully do this? nginx would seem like a better option)
- con: Is envoy only limited to http proxying. While it can also do HTTP/2 (for gRPC), this may limit the use cases for applications (e.g. we already have some applications that use UDP, or raw TCP connections)
- con: a userspace proxy will mask the connection details. I'm not sure that envoy currently implements the TCP PROXY protocol.

What are our safeguards against double circuit breaking? (i.e. having one circuit breaker for outbound client requests and one for inbound server requests). I don't think this is a good idea.

d) What modifications do clients (e.g. service.go) need to do to use the sidecar envoy as an outbound proxy?