Architecting for the Cloud, One Pattern at a Time on Chris Reddington

29 - The Sidecar and Ambassador Patterns

Fri, 05 Mar 2021 00:00:00 +0000

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:

27 - The Compute Resource Consolidation Pattern (Optimise for Cost!)

Fri, 19 Feb 2021 00:00:00 +0000

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.

26 - The Pub Sub, Priority Queue and Pipes and Filter Patterns

Fri, 12 Feb 2021 00:00:00 +0000

Chris and Willy cover three fundamental messaging patterns in this episode of Architecting for the Cloud, One Pattern at a Time.

Publish-Subscribe (Pub/Sub) transitions systems from point-to-point messaging (one sender, one receiver) to a multicast model where a single event triggers multiple independent subscribers simultaneously. Azure Service Bus topics and Azure Event Grid are the primary Azure implementations. Canonical use cases include:

Insurance aggregators fanning out quote requests to 15–50 backend services in parallel
Credit check pipelines triggering multiple reference agencies from a single event
Account sign-up flows dispatching to billing, provisioning, and notification services concurrently

Key benefit: subscribers are fully decoupled — adding a new consumer requires only a new subscription, with no changes to the producer.

23 - Gatekeeper and Valet Key Patterns - Secure your APIs and Resources

Fri, 22 Jan 2021 00:00:00 +0000

Continuing the ‘Architecting for the Cloud, one pattern at a time’ series, Chris and Peter Piper explore two closely related cloud design patterns that address a core challenge in distributed systems: how do you give clients access to exactly what they need — and nothing more?

The Gatekeeper Pattern

The Gatekeeper acts as a dedicated intermediary between untrusted clients (the public internet) and trusted backend services. Rather than exposing internal services directly, all traffic flows through the Gatekeeper, which can enforce:

21 - The Queue Based Load Levelling and Competing Consumers Pattern

Fri, 01 Jan 2021 09:30:00 +0000

Do you have an application with specific scalability and continuity-of-service requirements? What happens when your service is hit by heavy load — could performance or reliability issues cascade through your solution?

In this Architecting for the Cloud, One Pattern at a Time episode, Chris and Will Eastbury cover three closely related patterns that are almost always used together in high-throughput systems:

Queue-Based Load Levelling — use a message queue as a shock absorber to smooth dramatic traffic spikes, so a downstream service processes at a consistent rate regardless of inbound demand
Competing Consumers — scale out message processing by running multiple consumers in parallel, pulling from the same queue to clear backlogs faster
Asynchronous Request-Reply — retrofit async processing into existing synchronous architectures using a status-polling pattern (HTTP 202 / redirect), without tearing apart the existing application

Along the way, Willy and Chris discuss real-world analogies (drive-throughs, ticketing ballots, smart motorways), Azure Service Bus configuration considerations such as maximum queue depth, and how Azure Functions bindings can scale consuming instances dynamically based on queue depth. They also address distributed tracing with Application Insights and the critical reminder that these patterns introduce real complexity — and should only be adopted when requirements genuinely justify it.

20 - The Anti-corruption layer, Gateway Aggregation and Gateway Routing patterns

Wed, 30 Dec 2020 00:01:00 +0000

In this episode of the Architecting for the Cloud, One Pattern at a Time series, Peter Piper returns to walk through three powerful cloud design patterns that build on the Façade concept explored in earlier episodes.

What’s covered

Context reset: The Strangler pattern — a brief recap to set the scene for migration from legacy to modern systems
Anti-Corruption Layer (ACL) — how to prevent a legacy system’s data model from “corrupting” a new microservices domain; translating between old SOAP/REST contracts and modern REST APIs; how this enables high cohesion and low coupling through domain-driven design
Gateway Aggregation — reducing client chattiness by aggregating multiple backend service calls into a single response at the gateway layer; chatty I/O anti-patterns and their performance impact
Gateway Routing — layer-7 routing by IP, port, header, or URL path; decoupling consumers from versioned backend services; Azure load balancing options (Application Gateway, Azure Front Door, Traffic Manager, Azure Load Balancer) and when to use each
Azure service mapping — how Azure API Management, Application Gateway, and Front Door map to these patterns in practice
Cross-cutting concerns — resilience (single points of failure, HA/DR), observability (monitoring and logging), Infrastructure as Code for gateway configuration, and integration/regression/performance testing for each pattern
When not to use these patterns — anti-patterns for scenarios where a WAF/DDoS layer is a better fit than a full gateway

All three patterns share a common thread: a facade layer that decouples front-end consumers from back-end complexity, enabling independent evolution, safe versioning, and testability.

11 - The Geode Pattern - What is it and how can it be useful for my app?

Mon, 21 Dec 2020 00:00:00 +0000

You may have heard of patterns like the Retry pattern, Circuit Breaker, or CQRS — but have you heard of the Geode pattern?

In this Architecting for the Cloud, One Pattern at a Time episode, Chris and Will Eastbury — who contributed to the original Azure Architecture Center documentation for this pattern — explore how Geodes enable planet-scale, active-active applications.

Key concepts covered:

What is the Geode pattern? Geodes are identical, globally distributed compute nodes where all nodes actively serve any request. Unlike Deployment Stamps (which constrain a tenant to a specific stamp), all Geodes contain the same data, enabling any node to serve any user
Geodes vs Deployment Stamps: Deployment Stamps are tenant-scoped and support multi-tenancy models; Geodes prioritize global consistency and maximum compute utilization. The two patterns can be combined
Performance and availability: The primary benefit is low latency for globally distributed users, with high availability as a natural side effect. Azure Front Door acts as the intelligent global load balancer routing requests to the nearest healthy Geode
Data sovereignty considerations: Because data is replicated to all Geodes, organizations with strict regional data residency requirements need to plan carefully — potentially combining Geodes with Deployment Stamps for tenant-bounded slices
Active-active vs active-passive: Geodes are designed for scenarios where active-passive is too expensive or wasteful; all nodes are live and independently scalable
Hands-on demo: A globally distributed real-time voting application using Azure Functions (event bindings), Cosmos DB (change feed), and SignalR — demonstrating the event-sourcing and messaging aspects of the pattern in practice
Intelligent edge evolution: How this pattern naturally extends to IoT edge and 5G scenarios, with millions of tiny Geodes in roadside cabinets all maintaining configuration from a central service

This episode was originally recorded on 9th October 2020, but had some technical issues and was re-recorded on 21st December 2020.

17 - The Throttling, Retry and Circuit Breaker Patterns

Fri, 04 Dec 2020 00:00:00 +0000

How do you protect your infrastructure from traffic spikes, safeguard multi-tenant workloads from noisy neighbours, and handle transient failures gracefully? Chris and John Downs walk through three essential cloud resilience patterns that every developer building on Azure should understand. Part of the “Architecting for the Cloud, One Pattern at a Time” series.

The Throttling Pattern Protect your services and downstream dependencies from high or unexpected load. Rather than a simple binary on/off gate, throttling can degrade gracefully — disabling non-critical features under load, shaping traffic, or signalling clients via HTTP 429 with a Retry-After header. Azure services like Cosmos DB and Service Bus use this approach natively.

16 - The Backends for Frontends and Strangler Pattern with Peter Piper

Sun, 22 Nov 2020 00:00:00 +0000

Managing APIs across web, mobile, and multiple consumer types creates tight coupling that slows modernisation and makes versioning painful. In this episode, Chris Reddington is joined by Peter Piper to explore the Backend for Frontends (BFF) pattern — creating dedicated backends tailored to each consumer — alongside the Strangler Fig pattern for incrementally migrating legacy monoliths without disrupting existing clients. The Façade pattern also features as a key decoupling mechanism for smooth API migrations. Part of the “Architecting for the Cloud, One Pattern at a Time” series.