Introducción: capacidades transversales
Sidecar es proceso que corre con tu app. App + Sidecar = deployable unit. Sidecar maneja: logging, metrics, tracing, network policies. K8s inyecta automáticamente (Istio). App no sabe que existe. Ventaja: separación concerns, upgradear sidecars sin tocar app. Desventaja: overhead memoria/CPU. Usa para observabilidad, seguridad. NO para dominio logic.
Prompt: sidecar component beside main service, minimal style.
1. Naturaleza: pez limpiador
Un pez pequeño acompaña a otro para limpiar parásitos. El grande sigue su curso.
Prompt: small fish cleaning larger fish, soft illustration.
2. Mundo Real: observabilidad
Se agrega un sidecar para métricas y trazas en un servicio legado sin reescribirlo.
Prompt: sidecar collecting metrics, flat infographic.
3. Implementación en C#: Código Paso a Paso
// Servicio principal llama al sidecar local
await http.PostAsync("http://localhost:15000/trace", payload);El sidecar aplica políticas de reintento, circuit breaker o tracing.
4. Sidecar vs Biblioteca compartida
Sidecar evita acoplar código transversal en cada servicio.
La biblioteca compartida sigue siendo código embebido en cada servicio.
5. Diagrama UML
Prompt: UML diagram of sidecar with service, clean vector.
Prompt: sidecar flow diagram, minimal infographic.
⚠️ Cuándo NO Usar Sidecar
- Si el servicio no permite comunicación local.
- Si el overhead por proceso extra es crítico.
- Si necesitas cambios de lógica central, no transversal.
💪 Ejercicio
Define un sidecar para observabilidad en un servicio actual.
Conclusión
Sidecar mejora capacidades transversales sin tocar el core.