Sidecar

Deploy components of an application into a separate process or container to provide isolation and encapsulation. 

Sidecar pattern

An extra container in your pod to enhance or extend the functionality of the main container. In this pattern, we schedule a workload on the same hosts which is intended for specific things that don’t concern your application. One of the use cases can be log shipping. 

Example: Your application container is scheduled alongside a container is scheduled to take care of the logs generated by the application container.

Ambassador pattern

A container that proxy the network connection to the main container. This pattern is almost the same as sidecar pattern the difference is that in ambassador pattern every interaction to the world goes through the ambassador container. Here the containers are coupled means without ambassador pattern, the application cannot contact the outside world.

Example: Proxy where all the requests to the container go through an ambassador running alongside it. The main container can be accessed by the ambassador using local interfaces like the localhost.

When to use this pattern?

• Set of languages and frameworks.  

• A component is owned by a remote team or a different organization.  

• A component or feature must be co-located on the same host as the application.

• Independently updated.  

• Fine-grained control. 

When NOT to use this pattern?  

• Latency between the parent application and the sidecar can't be tolerated.

• Small applications.  

• Scaling differently or independently from the parent application