Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2021-04-08T18:53:21.053Z
Answers: You've described a service mesh almost.
Answers: Piotr Gwiazda
Answers: CC BY-SA 4.0
Answers: 2021-04-09T14:07:04.097Z
Answers: OP's scenario is basically the main motivation behind service meshes
Answers: Layman
Answers: CC BY-SA 4.0
Answers: 2021-04-08T16:31:08.797Z
Answers: 2021-04-08T16:31:08.797Z
Answers: Pablolibo
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2021-04-08T18:52:41.593Z
Answers: 2021-04-08T18:52:41.593Z
Answers: Piotr Gwiazda
Body: <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>
  
Tags: <containers><networking><microservices>
Title: Service to service communication - through proxy or direct?
UserDisplayName: jramm
ThreadText: # 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:
  
  1. Talking directly to each other?
  2. 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)
  
  
  ---
  
  