Patterns: Sidecars, Ambassadors, and Adapters Containers
Containers and architectural patterns: if you have developed distributed solutions, composed of multiple microservices, you will surely have used one of these approaches for solving “common” problems. If like me, you didn’t know that the pattern you chose for your implementation already had a name, here’s some theory for naming solutions that you have already verified to be “common sense” thanks to your experience. And maybe some more ideas for the future. Let’s see what the “sidecar”, “ambassadors” and “adapters” containers are.
Introduction
Your microservice is a container, which implements part of the business logic of your application. You will immediately realize that, in a distributed solution made up of many microservices, each with its own business purpose, there are a series of common functions independent of the business logic: logging, configuration, security are just some transversal aspects. Patterns are known as “sidecar”, “ambassador” or “adapter” arise precisely from the need to implement these functions outside the business container and to be reused where necessary throughout the entire solution.
