<p>The question is: why use a proxy to communicate both applications? What is the point or target (support SSL, security, availability between services?</p>
<p>In any case, you need 2 proxies, one in each app, in front of each application, it is the best way to use it.</p>
<p>You can also use tunnels, like SSH tunnel or Stunnel that support TLS</p>

CC BY-SA 4.0
2021-04-08T18:53:21.053Z
You've described a service mesh almost.
Piotr Gwiazda
CC BY-SA 4.0
2021-04-09T14:07:04.097Z
OP's scenario is basically the main motivation behind service meshes
Layman
CC BY-SA 4.0
2021-04-08T16:31:08.797Z
2021-04-08T16:31:08.797Z
Pablolibo
<p>Your challenges are:</p>
<ul>
<li>Service discovery (usually DNS-based, but there are other approaches)</li>
<li>Load balancing for multiple instances of services (server-side with a load balancer, or client-side with smart service discovery)</li>
<li>Encryption/TLS</li>
<li>Retry and circuit breaker</li>
</ul>
<p>There are few patterns</p>
<ul>
<li>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 &quot;public&quot; API through the gateway only, but not the &quot;private&quot; APIs that are internal-only</li>
<li>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.</li>
<li>Point-to-point communication with client-side load balancing (or none in a simplest situation)</li>
</ul>

CC BY-SA 4.0
2021-04-08T18:52:41.593Z
2021-04-08T18:52:41.593Z
Piotr Gwiazda
<p>A common scenario is two or more services behind a reverse proxy, typically each deployed in a container:</p>
<pre><code>| service 1 |          | service 2 |
           \            /
            \          /
             \        /
             | Proxy  |
</code></pre>
<p>Now the two services want to talk to each other. What are the pros/cons of:</p>
<ol>
<li>Talking directly to each other?</li>
<li>Going through the reverse proxy?</li>
</ol>
<p>Is there any standard best practice? Any potential security concerns?</p>

<containers><networking><microservices>
Service to service communication - through proxy or direct?
jramm
# Service to service communication - through proxy or direct?

(Asked by: username_0 on 2021-04-08)

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:

Talking directly to each other?
Going through the reverse proxy?

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

**Tags:** containers, networking, microservices


---

## 2 answers

### Answer by username_1 on 2021-04-08. Score: 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

> **Comments:**
> **username_2**: You've described a service mesh almost.  
> **username_3**: OP's scenario is basically the main motivation behind service meshes  

---

### Answer by username_2 on 2021-04-08. Score: 1

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)


---

