Ambassador Pattern

What is ambassador pattern?

As per this pattern you create helper services which is actually responsible for sending request to other application or services on behalf of your service. These helper services are called as Ambassador services.

Using ambassador pattern you offload the work for connectivity tasks like monitoring, logging, routing, security, application of circuit breakers to Ambassador Services without requiring to change your code.

An Ambassador service can be thought of as an out-of-process proxy that is co-located with the client.

Where it is applied?

• Generally this pattern is used with legacy applications where it is difficult to modify connectivity code but still there are requirements to extend connectivity tasks to enable security, routing, circuit breakers, monitoring, logging etc.
• When you want to offload all connectivity related to work to separate team.
• When you have lot of connectivity code, and same code is required by major number of your services.

How to implement it?

First step is to: 

• Put all connectivity code (configuration, client frameworks and libraries) into an external process that acts as a proxy between your application and external services. 

Second step is to deploy it:

• A sidecar to accompany the lifecycle of a consuming application or service. 
• If an ambassador is shared by multiple separate processes on a common host, it can be deployed as a daemon or Windows service. 
• If the consuming service is containerized, the ambassador should be created as a separate container on the same host, with the appropriate links configured for communication.
• In case of Kubernetes it can go in same POD of application.

What are the advantages of Ambassador Pattern?

• Simplifies the business application code as application may be connecting to multiple other services/applications each having its own libraries, configurations around connectivity, protocols for connection, authentication and authorization.
• Can be used to re-use connectivity code across applications.
• You can update and modify the ambassador without disturbing the application’s functionality. 
• You can offload the connectivity work to specialised teams which will also take care of security, networking, or authentication features.
• You can also use the ambassador pattern to standardize and extend instrumentation. 
  • Proxy can monitor performance metrics such as latency or resource usage.

What are key points to consider when using Ambassador Pattern?

• The proxy adds some latency overhead.
• Generalized features in the proxy like retries may not be required.
• Consider how you will package and deploy the proxy.
• Consider whether to use a single shared instance for all clients or an instance for each client.