CHAPTER 17 Ambassador Problem The  Ambassador  pattern is a specialized  Sidecar  responsible for hiding complexity and providing a unified interface for accessing services outside the Pod. In this chap‐ ter, we see how the  Ambassador  pattern can act as a proxy and decouple the main Pod from directly accessing external dependencies. Containerized services don’t exist in isolation and very often have to access other services that may be difficult to reach in a reliable way. The difficulty in accessing other services may be due to dynamic and changing addresses, the need for load bal‐ ancing of clustered service instances, an unreliable protocol, or difficult data formats. Ideally, containers should be single-purposed and reusable in different contexts. But if we have a container that provides some business functionality and consumes an external service in a specialized way, the container will have more than one responsibility. Consuming the external service may require a special service discovery library that we do not want to put in our container. Or we may want to swap different kinds of services by using different kinds of service discovery libraries and methods. This technique of abstracting and isolating the logic for accessing other services in the out‐ side world is the goal of this  Ambassador  pattern. To demonstrate the pattern, we will use a cache for an application. Accessing a local cache in the development environment may be a simple configuration, but in the pro‐ duction environment, we may need a client configuration that can connect to the dif‐ ferent shards of the cache. Another example would be consuming a service by 139 Solution