Service to service communication - through proxy or direct?

Question

A common scenario is two or more services behind a reverse proxy, typically each deployed in a container:

| service 1 |          | service 2 |
           \            /
            \          /
             \        /
             | Proxy  |

Now the two services want to talk to each other. What are the pros/cons of:

1. Talking directly to each other?
2. Going through the reverse proxy?

Is there any standard best practice? Any potential security concerns?

Answer 1

The question is: why use a proxy to communicate both applications? What is the point or target (support SSL, security, availability between services?

In any case, you need 2 proxies, one in each app, in front of each application, it is the best way to use it.

You can also use tunnels, like SSH tunnel or Stunnel that support TLS

Answer 2

Your challenges are:

• Service discovery (usually DNS-based, but there are other approaches)
• Load balancing for multiple instances of services (server-side with a load balancer, or client-side with smart service discovery)
• Encryption/TLS
• Retry and circuit breaker

There are few patterns

• API Gateway routing traffic for API calls not only for external traffic but also internally. Sometimes useful, but there are situations when you expose a "public" API through the gateway only, but not the "private" APIs that are internal-only
• A service mesh (Istio, LinkerD) - a sidecar is added to each service that is technically a reverse proxy (Envoy) and will handle mTLS/encryption, authentication, tracing, logging, circuit breaker, load balancing etc. The control plane of a service mesh keeps all proxies in sync.
• Point-to-point communication with client-side load balancing (or none in a simplest situation)