Ambassador and sidecar patterns

We have an application that interacts with several external services. We aim to monitor its health and collect logs and metrics while allowing the application to focus on its core business logic. To achieve this, we plan to use a proxy to communicate with external services(Ambassador pattern). Additionally, we will implement another proxy to manage logging, data metrics collection, and overall application health monitoring(Sidecar pattern).

As you can see, the ambassador and sidecar containers are separated and hosted on the same host with an application.

Data flow through ambassador and sidecar.

What standard components are in an ambassador container, and how do they interact?

Load Balancer:
- Distributes requests across multiple service instances
- Implements routing strategies (round-robin, weighted, etc.)
- Handles traffic management


Service Discovery:
- Maintains registry of available services
- Tracks service health and availability
- Updates service endpoints dynamically


Circuit Breaker:
- Prevents cascading failures
- Monitors service health
- Trips when error threshold reached
- Implements fallback mechanisms


Retry Handler:
- Manages retry attempts for failed requests
- Implements backoff strategies
- Handles temporary failures gracefully


SSL/TLS Termination:
- Manages secure connections
- Handles certificates
- Encrypts/decrypts traffic


Response Cache:
- Caches frequent responses
- Reduces external calls
- Improves response time


Monitoring/Telemetry:
- Tracks system metrics
- Monitors service health
- Provides debugging information

What standard components are in a sidecar container, and how do they interact?

Logging Sidecar:
- Log Collection: Captures application logs
- Log Processing: Formats and enriches logs
- Log Rotation: Manages log file sizes
- Log Shipping: Sends logs to central storage


Metrics Sidecar:
- Metrics Collection: Gathers application metrics
- Metrics Aggregation: Processes and summarizes metrics
- Alert Management: Monitors thresholds and triggers alerts
- Metrics Storage: Sends to time-series database


Config Sidecar:
- Config Watching: Monitors for configuration changes
- Config Validation: Ensures config integrity
- Config Distribution: Updates application with new configs
- Version Management: Tracks config versions


Security Sidecar:
- Certificate Management: Handles SSL/TLS certificates
- Secrets Management: Manages sensitive data
- Policy Enforcement: Implements security policies
- Authentication: Handles identity verification

Along with the benefits, we should also think about some disadvantages before applying.

Ambassador:
  Performance Impact:
  - Adds extra network hop causing increased latency
  - Consumes additional memory and CPU for proxying
  - Can become a bottleneck under high load
  
  Complexity:
  - Complex configuration for service discovery and load balancing
  - Difficult to debug network issues across multiple hops
  - Challenging to maintain in multiple environments
  
  Resource Cost:
  - Requires dedicated resources for each ambassador
  - Higher infrastructure costs
  - Additional monitoring overhead

Sidecar:
  Resource Overhead:
  - Each sidecar container adds CPU/memory overhead
  - Multiple containers share limited pod resources
  - Higher overall infrastructure cost
  
  Operational Complexity:
  - Difficult container lifecycle management
  - Complex inter-process communication
  - Harder to debug issues between containers
  
  Maintenance:
  - Version compatibility challenges between app and sidecars
  - More complex testing and deployment
  - Multiple components to monitor and maintain

When to avoid these patterns:

Simple Applications:
- Single service applications with basic needs
- Low traffic systems
- MVP or prototype development
- Limited operational resources

Resource Constraints:
- Limited infrastructure budget
- Small development team
- Basic deployment requirements