Ambassador

Create helper services that send network requests on behalf of a consumer service or application. An ambassador service can be thought of as an out-of-process proxy that is co-located with the client.

This pattern can be useful for offloading common client connectivity tasks such as monitoring, logging, routing, security (such as TLS), and resiliency patterns in a language agnostic way. It is often used with legacy applications, or other applications that are difficult to modify, in order to extend their networking capabilities. It can also enable a specialized team to implement those features.

When to use this pattern?  

• You need to build a common set of connectivity features for multiple Microservices, languages, frameworks…  

• You need to offload cross-cutting client connectivity concerns to infrastructure developers.

• You need to support cloud connectivity requirement in a legacy application.

When NOT to use this pattern?  

• When Network latency is critical.  

• When client connectivity features are consumed by a single language  

  • Better option would be a client library that is distributed to the development teams as a package.  

• When connectivity features cannot generalized 

Considerations  

• Adds some latency overhead  

• Retries might not safe unless all operations are idempotent  

• Allow clients to pass some context to the Ambassador  

  • For example, add HTTP header that allows the client to opt out of retry, or specify the maximum number of retires.  

• Consider whether to use a single shared instance for all Microservices, or an instance for each Microservice.