Kubernetes Patterns – Ambassador

 

Motivation

Recently, I’m studying kubernetes in-depth, mainly in part about how to use platform features to help me to work with distributed architectures.

During this journey, for my surprise, I’ve found many books of Kubernetes Patterns, and my god, these books opened my mind about “How to use Kubernetes effectively”.

My favorite one is Kubernetes Patterns, the book is awesome, it’s a kind of guide for me right now. The book describes many patterns and categorizes them in principles like Predictable Demands, Declarative Deployments, Health Probe, Managed Lifecycle and Automated Placement.

Today, I’ll talk about an important pattern related to network management techniques.

Let’s talk about Ambassador Pattern.

Ambassador

Context

When we are working with distributed systems, the network is the biggest challenge to solve, remember The Fallacies of Distributed Computing.

We need to do an effective strategy to work with outages, service discovery, circuit breakers, intelligent and dynamic routing rules, and time-outs.

In general, these things require a lot of configuration files envolving connection, authentication and authorization. These configurations should be dynamic as well, because in the distributed systems, addresses for instances, changes a lot during a certain timebox.

Of course, sometimes we are not able to handle these issues because our “application” is not able to handle it, our framework which the application is coded doesn’t support these features.

Also, we need to remember the containers Golden Rule, the container should exist for one single and small reason.

Maybe, handle these challenges into our application code cannot be a good idea, especially because sometimes we need to integrate with legacy applications.

The ambassador help us exactly at this point, let’s see how it happening.

Solution

Ambassador acts as “proxy” and hides all the complexities of accessing the external services.

We will put the ambassador container between our main application and external services connections. Just to remind, our ambassador container should be deployed in the same Kubernetes POD, which resides our main application container.

Using this simple approach we able to handle network failures, security, resiliency in the ambassador container, simple and effective way to handle these hards things to solve.

Look at the image below

The Ambassador Container should handle configurations related to Service Discovery, Time-outs, Circuit Breaker, Smart Routing and Security

Conclusion

The ambassador Pattern is very useful when we are working with distributed systems. It will reduce our main application complexity taking off the network management in our application code.

Remember: It will add some latency overhead. If network latency is a critical point for you, maybe you need to think about the ambassador adoption.

 

References

Kubernetes Patterns book

https://docs.microsoft.com/pt-br/azure/architecture/patterns/ambassador

One Reply to “Kubernetes Patterns – Ambassador”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.