Sidecar Pattern

Resumen

En el patrón Sidecar, un proceso o contenedor auxiliar se despliega junto a cada instancia del servicio principal. Ambos comparten recursos —red, almacenamiento— y ciclo de vida: cuando el servicio principal se inicia o se detiene, el sidecar también. El sidecar extiende funcionalidad sin tocar el código del servicio.

El ejemplo más conocido es el sidecar de proxy en un service mesh: Envoy se despliega como sidecar junto a cada microservicio y maneja tráfico, TLS, observabilidad y retries. El servicio solo habla con localhost y Envoy hace el resto.

Alcance y supuestos

Este paquete cubre el patrón Sidecar, su implementación en Kubernetes y su rol en service meshes. Asume familiaridad con contenedores y microservicios.

Modelo mental

Un asistente personal que viaja con un ejecutivo a todas sus reuniones. El ejecutivo no sabe manejar el protocolo de seguridad de cada edificio que visita, pero su asistente sí. En cada edificio, el asistente maneja la identificación, las llaves y las agendas. El sidecar es ese asistente.

Uso práctico

• ✅ Infraestructura transversal: logging, métricas, TLS, proxy.
• ✅ Migraciones graduales: sidecar traduce protocolos viejos a nuevos mientras el servicio principal no cambia.
• ❌ No para lógica de negocio: el sidecar es infraestructura.

Ejemplo trabajado: Envoy como sidecar en Kubernetes

Un microservicio en Go necesita mTLS, métricas y retries. En vez de implementarlo en Go, el equipo despliega Envoy como sidecar en el mismo Pod. El servicio habla a localhost:8080 y Envoy maneja TLS, métricas y retries. Cuando migran de REST a gRPC, solo cambian la configuración de Envoy —el servicio en Go no se toca.

Evidencia

• Kubernetes popularizó el patrón sidecar con Pods multi-contenedor. Istio y Linkerd lo implementan con Envoy como sidecar.