Ambassador Pattern: Description and Advice on Usage

Relationship to Sidecar and Sidecar Overview

The Ambassador pattern is a special case of the sidecar pattern. As such, it maintains most of the description, many of the benefits – and the drawbacks – of the Sidecar Pattern.

Sidecar (or sidekick) is useful for commonly used functional components that can be easily shared across services. These components, such as logging, metering, alerting, mark-down functionality, etc. are separately deployable (e.g. wrapped in separate containers) from the service that uses them but sit “alongside” the calling service for the purpose of minimizing shared service deployments. The easiest way to think of Sidecar is to think of it as a “daemonized” library deployed alongside any instance of a service (or within the same Kubernetes pod) that calls it.

Ambassador Pattern Overview

We use the term Ambassador (or call something an Ambassador service) when a Sidecar deployment proxies communication from one application (“Application A”) from/to a requesting/receiving process. When faced with the “Y2K” conversion crisis, many companies “wrapped” their existing solutions with other applications – applications that proxied inbound and outbound communication for the purposes of converting dates moving in and out of the legacy product.

Think of an Ambassador deployment as an alternative to this “wrapping” or modification of the call interfaces of an existing legacy component. The Ambassador takes traditional requests and translates them into appropriate requests for the legacy or existing solution. Ambassador also translates communication initiated from the legacy component and translates it into the appropriate communication for the remainder of the service fabric.

Because it is always implemented as a proxy (similar to the Strangler Pattern), Ambassador violates the AKF multiplicative effect of failure anti-pattern (services in depth – or long chains of services). That said, it still has huge opportunity to participate in a microservices architecture, especially when used to maintain the usefulness or extend the lifespan of older applications implemented as a service (legacy applications). Using an Ambassador service is often a wise approach to lower development costs of for legacy solutions that carry a low “modernization” financial return on investment.

Benefits of Ambassador

Ambassador comes with many benefits. Many are shared with Sidecar, but some are unique to the proxying nature of an Ambassador. Shared indicates benefits Ambassador shares with Sidecar, while unique indicates a benefit only Ambassador has:

• Unique: Creates fast time to market (TTM), low cost of development “wrapper” to convert legacy applications to increase their modern service benefits.
• Shared: Enables multiple languages (polyglot) and technologies for development teams. Teams that operate in multiple talent markets may find it easier to source talent with polyglot implementations.
• Shared: Conceptually easy interactions between components, typically consistent with interactions between all other services.
• Shared: Low latency compared to many services as the Ambassador lives in the same processing environment (VM, physical server, or Kubernetes pod) – albeit typically in a separate container.
• Shared: Allows for ownership by individual teams and as such engenders organizational scalability of a larger teams.
• Shared: Allows for independent release by teams of various shared usage components. As calling or called services change, the Ambassador can change without modifying the service for which it is an Ambassador (near where it sits).

Drawbacks to Ambassador

• Unique: Violation of service calls in series anti-pattern.
• Unique: Based on the above, higher probability of failure and a resulting lower overall availability relative to “wrapping” the service or completely modernizing it.
• Shared: High inter-process communication latency relative to libraries or “wrapping”. The loopback (or localhost) interface on a system (127.0.0.1) or the interface of the management/orchestration system (e.g. Kubernetes) will increase latency compared to transition of call flow through memory or process space.
• Shared: Containerization leads to multiple copies of the same code, and increased memory utilization for comparable operations relative to the use of libraries.
• Shared: Environments – fault isolation can become more difficult without special attention. VM technologies (Sidecar in a VM separate from the host or calling solution) is not an option as it is then a Fan Out or Mesh anti-pattern rather than a local call.

When to Use Ambassador

We often tell our clients that virtually no architectural modernization initiative should result in 100% of your software being updated. In fact, we often use the Pareto principal, or 80/20 rule, to determine what should be modernized (if anything at all). “What 20% of your solution represents 80% of the value and therefore the potential return on modernization?”

Ambassador is then a good way to address the otherwise financially dilutive efforts of a modernization – that potential 80% of your code that is infrequently updated, infrequently called but still of some value, or that creates the least value for your customers.

In addition to the modernization of the call interface to include legacy solutions into a modern services fabric, Ambassador gives teams the opportunity to enhance the capabilities of multiple applications with the low cost addition of a single codebase. The types of capabilities you want within the Ambassador service includes all of the capability that you can put in a single codebase but replicate across a legion of legacy solutions. These include but are not limited to capabilities like:

• Logging: Updated logging to ensure that errors are deposited into a modern log aggregation service (Splunk, Elk, Graylog and the like).
• Circuit Breakers: Insertion of circuit breakers to decrease the duration of failures or impact of high latency events.
• Metering or Rate Limiting: Capability to connect with any capabilities intended to monetize transactions or limit transactions from certain parties.
• Security: Updated security capabilities (potentially including rate limiting above) such as shared fraud analytics, fingerprinting or behavioral analysis.
• Targeting: Special cases may include increasing monetization activities by adding or analyzing tags specific to individuals or modifying responses to be more meaningful to users.

When to Avoid Ambassador

Within our Sidecar article, we admonish the reader to: “Never use a sidecar pattern for synchronous activities that must complete prior to generating a user response. Doing so will add some delay to end user response times.”

Recall that the Ambassador is a special instance of Sidecar, and its whole purpose is to create a proxy. The only reason to do so is to leverage existing implementations that have value, but whose return on investment for updating is low relative to the return. The “return” here is the value the effort brings relative to the cost of the effort.

Cases in which one should avoid Ambassador include the following:

• High Debt and High Updates to Legacy Solution: If the legacy solution carries a great amount of technical debt and is frequently updated, Ambassador may not be an appropriate pattern. Assuming that the interest on the aforementioned debt is a high cost to update the legacy solution, and that the number of changes to the legacy solution is high, there should be a corresponding return to rewriting the solution. Said return should be higher velocity at similar development costs and should easily be supported through traditional discounted cash flow analysis, or a net present value analysis of continuing to use the existing service and refactoring the legacy service.
• Mesh Proxies: Never implement a mesh proxy in an Ambassador service or pattern. The proxy you implement should handle communication transformation and the modernization of the service for anything that can be placed in a sidecar. But embedding the knowledge of all instance endpoints for all services is an anti-pattern for the reasons we describe here.