What is the Adapter pattern in the context of microservice containers?

The Adapter pattern (container / structural variant) places a sidecar container alongside the main container to normalise the main container's output into a standard interface that the surrounding infrastructure expects — without modifying the main application. It is essentially a structural translator that makes a non-conforming service look conforming to monitoring, logging, or management infrastructure.

Concrete examples:

• Legacy log format to structured JSON — a legacy Java service writes logs in a custom text format. An Adapter sidecar reads the log file, parses the custom format, and re-emits structured JSON to stdout so the standard Fluentd pipeline can process it identically to every other service.
• Non-standard metrics to Prometheus format — a third-party binary exposes metrics on a proprietary UDP endpoint. An Adapter sidecar reads those metrics and exposes them at /metrics in Prometheus exposition format, making the service scrape-able by Prometheus without any changes to the binary.
• Legacy health endpoint normalisation — a vendor application returns health status in a non-standard format. The Adapter translates it to the standard { "status": "UP" } JSON that Kubernetes probes expect.

Adapter vs Ambassador: Both are sidecar specialisations. The Ambassador manages outbound connectivity (egress traffic, retries, circuit breaking). The Adapter manages output format normalisation (translating the service's emitted data — logs, metrics, health — into a standard interface). An Ambassador speaks on behalf of the app to the outside world; an Adapter speaks on behalf of the app to the infrastructure tooling.