29 - The Sidecar and Ambassador Patterns
Modernising legacy applications doesn’t have to mean rewriting them from scratch. Two cloud design patterns — the Sidecar and the Ambassador — provide elegant ways to extend legacy services with modern capabilities, incrementally and safely. In this episode of Architecting for the Cloud, one pattern at a time, Chris and Peter break down both patterns.
The Ambassador Pattern
The Ambassador pattern places a proxy service between a client and an upstream service or external dependency. This proxy handles cross-cutting concerns that the underlying application doesn’t natively support:
- Retry logic and exponential backoff
- Circuit breaking to prevent cascading failures
- Request routing and load balancing
- Protocol translation (e.g., HTTP/1.1 to gRPC)
The ambassador is transparent to the client and can be updated or replaced without touching the legacy application. It’s particularly valuable when applying consistent resiliency policies across multiple downstream dependencies or when integrating with external services your team doesn’t control.
The Sidecar Pattern
The Sidecar pattern co-locates a helper process alongside the primary application — both deployed within the same unit (e.g., a Kubernetes pod). The sidecar shares the same lifecycle as the main process and can:
- Handle logging, telemetry, and trace shipping
- Manage configuration injection and secrets
- Run health checks and readiness probes
- Perform TLS termination
Service meshes like Istio and Linkerd are real-world implementations of the sidecar pattern at scale, injecting proxy containers automatically into every pod.
Choosing Between the Two
The Sidecar and Ambassador patterns are closely related and often reference each other in documentation. The key distinction: sidecars extend the application itself from within, while ambassadors act as a gateway on behalf of the application. Both are powerful tools in the modernisation toolkit, especially when combined with the Strangler Fig pattern for incremental legacy migration.
Related Content
27 - The Compute Resource Consolidation Pattern (Optimise for Cost!)
Are you running dedicated compute for every tenant, microservice, or application instance — and paying for it? The Compute Resource Consolidation pattern shows you how to consolidate tasks onto shared infrastructure, such as a single AKS cluster with namespace isolation or an Azure SQL elastic pool, to reduce costs and management overhead. This episode explores the key trade-offs: blast radius containment, noisy neighbour contention, scalability profiles, and multi-tenancy strategies. Part of the "Architecting for the Cloud, One Pattern at a Time" series.
20 - The Anti-corruption layer, Gateway Aggregation and Gateway Routing patterns
Cloud with ChrisPeter Piper joins Chris Reddington for another episode in the Architecting for the Cloud, One Pattern at a Time series. Building on the Façade and Strangler patterns, they explore three related cloud design patterns: the Anti-Corruption Layer (translating between legacy and modern domain models), Gateway Aggregation (collapsing multiple backend calls into a single client response), and Gateway Routing (layer-7 routing to decouple consumers from versioned backend services). Real Azure service examples — including API Management, Application Gateway, and Azure Front Door — are used throughout.
18 - Tales from the Real World - Defying Gravity.. The magic behind Flight Simulator 2020
What's actually powering Microsoft Flight Simulator 2020 — and what can cloud architects learn from it? Chris Reddington takes to the virtual skies over Queensland with former colleague Cam Adams, flying a Cessna 172 from Archerfield aerodrome while discussing the real Azure services behind one of the most technically ambitious games ever made. From CDN-based asset distribution and event-driven live weather to PlayFab game backends and DDoS protection — this is cloud architecture on the fly.