Container Design Pattern – Ambassador Pattern
The Ambassador pattern creates a container that acts as a proxy between the main container and the external system. This enables the main container to offload cumbersome processes of connecting to an external system to a proxy(ambassador) container. Typically this is used along with any application which is difficult to modify like a legacy application.
The Ambassador container is deployed as a sidecar container along with the main container in the same pod. This allows developers to code in a manner as it is connecting to only one server on the localhost. Ambassador containers in return will take care of managing authentication, authorization, and networking connectivity to an external system.
The main container that interacts with the caching server(eg. Memcache servers) will connect to the ambassador container as if it is containing to single cache server on the localhost. Ambassador container will connect to the external cache server(which can be one server or multiple). If any change is required in the way it needs to connect to an external system, only ambassador containers need to be modified without impacting the main container.
- Like any other single node multi-container pattern this also is developed/managed independently.
- It can be upgraded independently.
- It provides a standard set of features that can in different pods having a different set of the main container.
The main disadvantage of ambassador container is it creates latency due to proxy.
Sidecar, Adapter, and Ambassador pattern are part of the single node multiple container design patterns. In all these patterns secondary container is deployed in the same pod as the main container.
In continuation of this series, we will be going through multi-node design pattern in the next blog.