Resilient cloud-based applications require features such as circuit breaking, routing, metering and monitoring, and the ability to make network-related configuration updates. It may be difficult or impossible to update legacy applications or existing code libraries to add these features, because the code is no longer maintained or can’t be easily modified by the development team.
Network calls also require substantial configuration for connection, authentication, and authorization. If these calls are used across multiple applications, built using multiple languages and frameworks, the calls must be configured for each of these instances. In addition, network and security functionality may need to be managed by a central team within your organization. With a large code base, it can be risky for that team to update application code they aren’t familiar with.
Put client frameworks and libraries into an external process that acts as a proxy between your application and external services. Deploy the proxy on the same host environment as your application to allow control over routing, resiliency, security features, and to avoid any host-related access restrictions. You can also use the ambassador pattern to standardize and extend instrumentation. The proxy can monitor performance metrics such as latency or resource usage, and this monitoring happens in the same host environment as the application.
Use this pattern when you:
This code sets up a connection to the Kubernetes API server and creates a Kubernetes client.
It then creates an HTTP handler function that routes requests to the appropriate microservice based on the request parameters and makes a request to the target microservice using the Kubernetes client.
The response from the target microservice is then written back to the client.
Keep in mind that this is just a simplified example and may not include all of the features and functionality that you might want in a real-world ambassador service.
The Ambassador pattern adds an additional layer of complexity to your application by introducing an extra service that acts as a proxy between the client and the target microservices. This can make it more difficult to understand and maintain the application.
The Ambassador pattern can potentially add overhead to your application by requiring an extra network hop for each request. This can impact the performance of your application, particularly for high-traffic applications or applications that require low latency.
The Ambassador pattern may not provide all of the features and functionality that you need for your application. For example, if you need to add advanced routing or load balancing capabilities, you may need to use a more feature-rich ingress controller.
In general, the Ambassador pattern is most suitable for relatively simple applications that do not require advanced routing or load balancing capabilities. If your application has more complex requirements, you may want to consider using a different approach, such as an ingress controller or a service mesh.