Cloud Design Pattern - Ambassador Pattern

Cloud Design Patterns: Cloud design patterns are reusable solutions we use to address common recurrent problems in the world of Cloud computing. By making use of reusable patterns in the cloud, we can ensure that we are following best design patterns and are able to reuse commonly used scenarios and able to simply administration, development and reusability of any cloud applications. These patterns can be used for any Cloud providers.

Ambassador Pattern

In this article, we will look at what Ambassador pattern is. Lets assume our application is based on Microservices based architecture and its using container. Lets assume our Microservice PlayApp is trying to connect a remote service named JumboApp. In this case, the communication would be simply be sending a request and receiving a response. You might wonder why are we going to implement this pattern for this simple thing i.e. sending a request and receiving a response. One reason being for a retry request. Lets assume our Microservice PlayApp is sending a request but then its unable to receive response from remote service i.e. JumboApp. In this case, our Microservice PlayApp will keep retrying until, it gets a response from remote service JumboApp.

One good example for the above one is lets say a database deadlock. Lets say, the database has a deadlock because there are other operations ongoing until database takes another request. In this case, our Microservice will only be able to get a response from a remote service i.e. database until the database engine is free and is able to process requests.

Another thing is to take care of circuit breaking pattern. You can consider using circuit breaking feature for a long term failures that takes around 15-30 mins or even more whereas retry is for a short term failures. In a distributed environment, we may have any kinds of failures, it can be network failures, it can even be a remote service failures, at that moment it doesn’t make sense for our Microservice named PlayApp to keep sending requests to remote service JumboApp. In this case, it can also be possible that when our Microservice PlayApp is continuously sending requests, it may be out of resources and our Microservice PlayApp may completely be unavailable. So, this is where circuit breaking pattern comes in really useful. In this even if Remote service JumboApp is down, our Microservice PlayApp will not send any requests.

Next one is monitoring, we must implement logging and monitoring to keep checking what requests are we sending to remote service and what responses are we receiving from remote service. 

Another important point is to take care of security. To ensure that when our Microservice PlayApp wants to communicate to remote service JumboApp, it should use secure channel.

You can consider using all these patterns i.e. retry, circuit breaking, monitoring and security. But, what if we have more than one Microservices, is it always advisable to go with separate pattern working with these Microservices like as in below diagram?

By repeating these patterns, we are going to make the system complex. Also, lets take example you want to implement one security feature to these, you will have to repeat for all Microservices. Plus, you will have to take care of redeploying it for every Microservices which will need massive development work. This is where the Ambassador pattern comes into the picture. So, essentially all patterns we considered earlier can be clubbed together in one container called Ambassador which will provide all the features you are looking for i.e. Retry, Circuit breaker, Monitoring, security.

For this, you need to be aware of few considerations:

1. This pattern may add some latency overhead.

2. Retries might not be safe until all operations are idempotent

3. You may consider using single instance for all Microservices for Ambassador or multiple instances of each Microservice.

When to use this pattern?

1. You need to build a common set of connectivity features for multiple Microservices, languages and frameworks.

2. You need to support cloud connectivity requirements in legacy applications.