Container Design Pattern – Adapter Pattern
In the adapter pattern- the adapter container provides a simplified and unified response to an external system. As mentioned in the original article – Adapter containers standardize and normalize output. In this pattern, the adapter container resides in the same pod as the main container(similar to sidecar) and provides a homogenous response to the outside world.
So how is it different from sidecar? Similar to the sidecar, the Adapter container is also deployed in the same pod as the main container and uses the same resource, but there is a slight difference between adapter and sidecar container.
Sidecar provides a way to extend the functionality of the main container whereas Adapter provides a uniform interface for the outside world. More on sidecar pattern.
A system that collects logs and other monitoring related data and generates various reports. This monitoring system requires data in a unified format. Different containers can be producing monitoring data in different formats (log files, JMX, StatsD, etc). Adapter containers consume this data and convert in a format that the external monitoring system will be able to understand.
- Provide a simplified and uniform view of application to heterogeneous services
- Similar to the sidecar, the adapter container can also be developed/managed independently
- This can be reused alongside different main container that needs to provide a uniform response to any external system
In the next blog, we are going to cover “Ambassador Pattern”