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