From 12976d87013e206c41d86a54535ff9e3efc4e52b Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 15:44:37 +0000 Subject: [PATCH 01/27] Add WAF for Ambassador pattern --- docs/patterns/ambassador-content.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/patterns/ambassador-content.md b/docs/patterns/ambassador-content.md index 74c6e4287f..dee66359ae 100644 --- a/docs/patterns/ambassador-content.md +++ b/docs/patterns/ambassador-content.md @@ -40,6 +40,17 @@ This pattern may not be suitable: - When client connectivity features are consumed by a single language. In that case, a better option might be a client library that is distributed to the development teams as a package. - When connectivity features cannot be generalized and require deeper integration with the client application. +## Workload design + +An architect should evaluate how the Ambassador pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | The network communications mediation point facilitated by this pattern provides an opportunity to add reliability patterns to network communication, such as retry or buffering.

- [RE:07 Self-preservation](/azure/well-architected/reliability/self-preservation) | +| [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | This pattern provides an opportunity to augment security on network communications that could not have been handled by the client directly.

- [SE:06 Network controls](/azure/well-architected/security/networking)
- [SE:07 Encryption](/azure/well-architected/security/encryption) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Example The following diagram shows an application making a request to a remote service via an ambassador proxy. The ambassador provides routing, circuit breaking, and logging. It calls the remote service and then returns the response to the client application: From 00ae1946b97f3dd8379a18725a1656490a921d93 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 15:50:05 +0000 Subject: [PATCH 02/27] WAF + Anti-corruption Layer pattern --- docs/patterns/anti-corruption-layer-content.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/patterns/anti-corruption-layer-content.md b/docs/patterns/anti-corruption-layer-content.md index 01555c450e..ed44351fc0 100644 --- a/docs/patterns/anti-corruption-layer-content.md +++ b/docs/patterns/anti-corruption-layer-content.md @@ -39,6 +39,16 @@ Use this pattern when: This pattern may not be suitable if there are no significant semantic differences between new and legacy systems. +## Workload design + +An architect should evaluate how the Anti-corruption Layer pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | This pattern helps ensure that new component design remains uninfluenced by legacy implementations that might have different data models or business rules when you integrate with these legacy systems and it can reduce technical debt in new components while still supporting existing components.

- [OE:04 Tools and processes](/azure/well-architected/operational-excellence/tools-processes) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Related resources - [Strangler Fig pattern](./strangler-fig.yml) From 46811f2bb700a272f4889fa7575165bfcdd52999 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 15:53:20 +0000 Subject: [PATCH 03/27] WAF + Asynchronous Request-Reply pattern --- docs/patterns/async-request-reply-content.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/patterns/async-request-reply-content.md b/docs/patterns/async-request-reply-content.md index 6e663b118f..fc6bae8bb5 100644 --- a/docs/patterns/async-request-reply-content.md +++ b/docs/patterns/async-request-reply-content.md @@ -92,6 +92,16 @@ This pattern might not be suitable when: - You can use server-side persistent network connections such as WebSockets or SignalR. These services can be used to notify the caller of the result. - The network design allows you to open up ports to receive asynchronous callbacks or webhooks. +## Workload design + +An architect should evaluate how the Asynchronous Request-Reply pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | Decoupling the request and reply phases of interactions for processes that don't need immediate answers improves the responsiveness and scalability of systems. As an asynchronous appproach, you can maximize concurrency on the server side and schedule work to be completed as capacity allows.

- [PE:05 Scaling and partitioning](/azure/well-architected/performance-efficiency/scale-partition)
- [PE:07 Code and infrastructure](/azure/well-architected/performance-efficiency/optimize-code-infrastructure) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Example The following code shows excerpts from an application that uses Azure Functions to implement this pattern. There are three functions in the solution: From 396096268cbdca25c70a014767afd4570acac520 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 16:05:24 +0000 Subject: [PATCH 04/27] WAF + Backends for Frontends pattern --- docs/patterns/backends-for-frontends-content.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/patterns/backends-for-frontends-content.md b/docs/patterns/backends-for-frontends-content.md index d1bf75ed8f..8c0a3213af 100644 --- a/docs/patterns/backends-for-frontends-content.md +++ b/docs/patterns/backends-for-frontends-content.md @@ -45,6 +45,18 @@ This pattern may not be suitable: - When interfaces make the same or similar requests to the backend. - When only one interface is used to interact with the backend. +## Workload design + +An architect should evaluate how the Backends for Frontends pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | Having separate services that are exclusive to a specific frontend interface contains malfunctions so the availability of one client might not affect the availability of another client's access. Also, when you treat various clients differently, you can prioritize reliability efforts based on expected client access patterns.

- [RE:02 Critical flows](/azure/well-architected/reliability/identify-flows)
- [RE:07 Self-preservation](/azure/well-architected/reliability/self-preservation) | +| [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | Because of service separation introduced in this pattern, the security and authorization in the service layer that supports one client can be tailored to the functionality required by that client, potentially reducing the surface area of an API and lateral movement among different backends that might expose different capabilities.

- [SE:04 Segmentation](/azure/well-architected/security/segmentation)
- [SE:08 Hardening resources](/azure/well-architected/security/harden-resources) | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | The backend separation enables you to optimize in ways that might not be possible with a shared service layer. When you handle individual clients differently, you can optimize performance for a specific client's constraints and functionality.

- [PE:02 Capacity planning](/azure/well-architected/performance-efficiency/capacity-planning)
- [PE:09 Critical flows](/azure/well-architected/performance-efficiency/prioritize-critical-flows) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Next steps - [Pattern: Backends For Frontends](https://samnewman.io/patterns/architectural/bff/) From 87f956a91e5acbaeb69c7821caa7b90331df537c Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 16:25:34 +0000 Subject: [PATCH 05/27] WAF + Bulkhead pattern --- docs/patterns/bulkhead-content.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/patterns/bulkhead-content.md b/docs/patterns/bulkhead-content.md index 3c727c574b..a0662046cb 100644 --- a/docs/patterns/bulkhead-content.md +++ b/docs/patterns/bulkhead-content.md @@ -52,6 +52,18 @@ This pattern may not be suitable when: - Less efficient use of resources may not be acceptable in the project. - The added complexity is not necessary +## Workload design + +An architect should evaluate how the Bulkhead pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | The failure isolation strategy introduced through the intentional and complete segmentation between components attempts to contain faults to just the bulkhead that's experiencing the problem, preventing impact to other bulkheads.

- [RE:02 Critical flows](/azure/well-architected/reliability/identify-flows)
- [RE:07 Self-preservation](/azure/well-architected/reliability/self-preservation) | +| [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | The segmentation between components helps constrain security incidents to the compromised bulkhead.

- [SE:04 Segmentation](/azure/well-architected/security/segmentation) | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | Each bulkhead can be individually scalable to efficiently meet the needs of the task that's encapsulated in the bulkhead.

- [PE:02 Capacity planning](/azure/well-architected/performance-efficiency/capacity-planning)
- [PE:05 Scaling and partitioning](/azure/well-architected/performance-efficiency/scale-partition) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Example The following Kubernetes configuration file creates an isolated container to run a single service, with its own CPU and memory resources and limits. From 0df6efd15e534da224450f54ad76e0a63a2d25d2 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 16:42:16 +0000 Subject: [PATCH 06/27] WAF + Cache-Aside pattern --- docs/patterns/cache-aside-content.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/patterns/cache-aside-content.md b/docs/patterns/cache-aside-content.md index 29d453d6f1..11d1bc44af 100644 --- a/docs/patterns/cache-aside-content.md +++ b/docs/patterns/cache-aside-content.md @@ -44,6 +44,17 @@ This pattern might not be suitable: - When the cached data set is static. If the data will fit into the available cache space, prime the cache with the data on startup and apply a policy that prevents the data from expiring. - For caching session state information in a web application hosted in a web farm. In this environment, you should avoid introducing dependencies based on client-server affinity. +## Workload design + +An architect should evaluate how the Cache-Aside pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | Caching creates data replication and, in limited ways, can be used to preserve the availability of frequently accessed data if the origin data store is temporarily unavailable. Additionally, if there's a malfunction in the cache, the workload can fall back to the origin data store.

- [RE:05 Redumdancy](/azure/well-architected/reliability/redundancy) | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | Better performance in your workload can be obtained when using a cache for read-heavy data that doesn't change often and your workload is designed to tolerate a certain amount of staleness.

- [PE:08 Data performance](/azure/well-architected/performance-efficiency/optimize-data-performance)
- [PE:12 Continuous performance optimization](/azure/well-architected/performance-efficiency/continuous-performance-optimize) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Example In Microsoft Azure you can use Azure Cache for Redis to create a distributed cache that can be shared by multiple instances of an application. From 0456b7f05678c7afad4826bb980d80ac9fd8a083 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 16:58:34 +0000 Subject: [PATCH 07/27] WAF + Choreography pattern --- docs/patterns/choreography-content.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/patterns/choreography-content.md b/docs/patterns/choreography-content.md index 22e52b1d5b..33835e10ef 100644 --- a/docs/patterns/choreography-content.md +++ b/docs/patterns/choreography-content.md @@ -46,6 +46,17 @@ The orchestrator centrally manages the resiliency of the workflow and it can bec Each service isn't only responsible for the resiliency of its operation but also the workflow. This responsibility can be burdensome for the service and hard to implement. Each service must retry transient, nontransient, and time-out failures, so that the request terminates gracefully, if needed. Also, the service must be diligent about communicating the success or failure of the operation so that other services can act accordingly. +## Workload design + +An architect should evaluate how the Choreography pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | Because the distributed components in this pattern are autonomous and designed to be replaceable, you can modify the workload with less overall change to the system.

- [OE:04 Tools and processes](/azure/well-architected/operational-excellence/tools-processes) | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | This pattern provides an alternative when performance bottlenecks occur in a centralized orchestration topology.

- [PE:02 Capacity planning](/azure/well-architected/performance-efficiency/capacity-planning)
- [PE:05 Scaling and partitioning](/azure/well-architected/performance-efficiency/scale-partition) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Example This example shows the choreography pattern with the [Drone Delivery app](https://github.com/mspnp/microservices-reference-implementation). When a client requests a pickup, the app assigns a drone and notifies the client. From bf296cf70947b952372c6c42ecdc64170edc48da Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 17:05:38 +0000 Subject: [PATCH 08/27] WAF + Circuit Breaker pattern --- docs/patterns/circuit-breaker-content.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/patterns/circuit-breaker-content.md b/docs/patterns/circuit-breaker-content.md index 732018edbf..61ee008b4b 100644 --- a/docs/patterns/circuit-breaker-content.md +++ b/docs/patterns/circuit-breaker-content.md @@ -78,6 +78,17 @@ This pattern isn't recommended: - For handling access to local private resources in an application, such as in-memory data structure. In this environment, using a circuit breaker would add overhead to your system. - As a substitute for handling exceptions in the business logic of your applications. +## Workload design + +An architect should evaluate how the Circuit Breaker pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | This pattern prevents overloading a faulting dependency. You can also use this pattern to trigger graceful degradation in the workload. Circuit breakers are often coupled with automatic recovery to provide both self-preservation and self-healing.

- [RE:03 Failure mode analysis](/azure/well-architected/reliability/failure-mode-analysis)
- [RE:07 Transient faults](/azure/well-architected/reliability/handle-transient-faults)
- [RE:07 Self-preservation](/azure/well-architected/reliability/self-preservation) | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | This pattern avoids the retry-on-error approach which can lead to excessive resource utilization during dependency recovery and can also overload performance on a dependency that's attempting recovery.

- [PE:07 Code and infrastructure](/azure/well-architected/performance-efficiency/optimize-code-infrastructure)
- [PE:11 Live-issues responses](/azure/well-architected/performance-efficiency/respond-live-performance-issues) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Example In a web application, several of the pages are populated with data retrieved from an external service. If the system implements minimal caching, most hits to these pages will cause a round trip to the service. Connections from the web application to the service could be configured with a timeout period (typically 60 seconds), and if the service doesn't respond in this time the logic in each web page will assume that the service is unavailable and throw an exception. From 347d0e593804c95747afbbdf3156204a3a082c4e Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 17:15:48 +0000 Subject: [PATCH 09/27] WAF + Claim-Check pattern --- docs/patterns/claim-check-content.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/docs/patterns/claim-check-content.md b/docs/patterns/claim-check-content.md index 33c7f0a209..c2914e1b15 100644 --- a/docs/patterns/claim-check-content.md +++ b/docs/patterns/claim-check-content.md @@ -35,6 +35,19 @@ This pattern could be used whenever a message cannot fit the supported message l The pattern can also be used if the payload should be accessed only by services that are authorized to see it. By offloading the payload to an external resource, stricter authentication and authorization rules can be put in place, to ensure that security is enforced when sensitive data is stored in the payload. +## Workload design + +An architect should evaluate how the Claim-Check pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | Message buses don't provide the same reliability and disaster recovery that are often present in dedicated data stores, so separating the data from the message can provide increased reliability for the underlying data. This separation also allows for a message queue recovery approach after a disaster.

- [RE:03 Failure mode analysis](/azure/well-architected/reliability/failure-mode-analysis)
- [RE:09 Disaster recovery](/azure/well-architected/reliability/disaster-recovery) | +| [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | This pattern supports keeping sensitive data out of message bodies, instead keeping it managed in a secured data store. This configuration enables you to establish stricter authorization to support access to the sensitive data from services that are expected to use the data, but remove visibility from ancillary services like queue monitoring solutions.

- [SE:03 Data classification](/azure/well-architected/security/data-classification)
- [SE:04 Segmentation](/azure/well-architected/security/segmentation) | +| [Cost Optimization](/azure/well-architected/cost-optimization/checklist) is focused on **sustaining and improving** your workload's **return on investment**. | Messaging systems often impose limits on message size, and increased size limits is often a premium feature. Reducing the size of message bodies might enable you to use a cheaper messaging solution.

- [CO:07 Component costs](/azure/well-architected/cost-optimization/optimize-component-costs)
- [CO:09 Flow costs](/azure/well-architected/cost-optimization/optimize-flow-costs) | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | This pattern improves the efficiency and performance of message publishers, subscribers, and the message bus itself when the system handles large data payloads. It works by decreasing the size of messages and ensuring that consumers retrieve payload data only if necessary and at an opportune time.

- [PE:05 Scaling and partitioning](/azure/well-architected/performance-efficiency/scale-partition)
- [PE:12 Continuous performance optimization](/azure/well-architected/performance-efficiency/continuous-performance-optimize) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Examples On Azure, this pattern can be implemented in several ways and with different technologies, but there are two main categories. In both cases, the receiver has the responsibility to read the claim check and use it to retrieve the payload. From f34484ecfe27a266b5e360ae19b0fd10abff6d2c Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 17:19:45 +0000 Subject: [PATCH 10/27] WAF + Compensating Transaction pattern --- docs/patterns/compensating-transaction-content.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/patterns/compensating-transaction-content.md b/docs/patterns/compensating-transaction-content.md index 288e8e8410..e085cc6a0a 100644 --- a/docs/patterns/compensating-transaction-content.md +++ b/docs/patterns/compensating-transaction-content.md @@ -58,6 +58,16 @@ Consider the following points when you decide how to implement this pattern: Use this pattern only for operations that must be undone if they fail. If possible, design solutions to avoid the complexity of requiring compensating transactions. +## Workload design + +An architect should evaluate how the Compensating Transaction pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | Compensation actions address malfunctions in critical workload paths by using processes like directly rolling back data changes, breaking transaction locks, or even executing native system behavior to reverse the effect.

- [RE:02 Critical flows](/azure/well-architected/reliability/identify-flows)
- [RE:09 Disaster recovery](/azure/well-architected/reliability/disaster-recovery) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Example Customers use a travel website to book itineraries. A single itinerary might consist of a series of flights and hotels. A customer who travels from Seattle to London and then on to Paris might perform the following steps when creating an itinerary: From 7f329980aa65b7d66cd1d1ad8679ff7dc39775d2 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 17:25:08 +0000 Subject: [PATCH 11/27] WAF + Competing Consumers pattern --- docs/patterns/competing-consumers-content.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/patterns/competing-consumers-content.md b/docs/patterns/competing-consumers-content.md index 909da3d361..60303cdf7a 100644 --- a/docs/patterns/competing-consumers-content.md +++ b/docs/patterns/competing-consumers-content.md @@ -64,6 +64,18 @@ This pattern might not be useful when: > Some messaging systems support sessions that enable a producer to group messages together and ensure that they're all handled by the same consumer. This mechanism can be used with prioritized messages (if they are supported) to implement a form of message ordering that delivers messages in sequence from a producer to a single consumer. +## Workload design + +An architect should evaluate how the Competing Consumers pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | This pattern builds redundancy in queue processing by treating consumers as replicas, so an instance failure doesn't prevent other consumers from processing queue messages.

- [RE:05 Redundancy](/azure/well-architected/reliability/redundancy)
- [RE:07 Background jobs](/azure/well-architected/reliability/background-jobs) | +| [Cost Optimization](/azure/well-architected/cost-optimization/checklist) is focused on **sustaining and improving** your workload's **return on investment**. | This pattern can help you optimize costs by enabling scaling that's based on queue depth, down to zero when the queue is empty. It can also optimize costs by enabling you to limit the maximum number of concurrent consumer instances.

- [CO:05 Rate optimization](/azure/well-architected/cost-optimization/get-best-rates)
- [CO:07 Component costs](/azure/well-architected/cost-optimization/optimize-component-costs) | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | Distributing load across all consumer nodes increases utilization and dynamic scaling based on queue depth minimize overprovisioning.

- [PE:05 Scaling and partitioning](/azure/well-architected/performance-efficiency/scale-partition)
- [PE:07 Code and infrastructure](/azure/well-architected/performance-efficiency/optimize-code-infrastructure) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Example Azure provides Service Bus Queues and Azure Function queue triggers that, when combined, are a direct implementation of this cloud design pattern. Azure Functions integrate with Azure Service Bus via triggers and bindings. Integrating with Service Bus allows you to build functions that consume queue messages sent by publishers. The publishing application(s) will post messages to a queue, and consumers, implemented as Azure Functions, can retrieve messages from this queue and handle them. From 5878da29f6b956df3b39ef72c2c91224b50b0494 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 18:38:22 +0000 Subject: [PATCH 12/27] WAF + Compute Resource Consolidation pattern --- .../compute-resource-consolidation-content.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/patterns/compute-resource-consolidation-content.md b/docs/patterns/compute-resource-consolidation-content.md index 843c7bdbbe..6cb4da0152 100644 --- a/docs/patterns/compute-resource-consolidation-content.md +++ b/docs/patterns/compute-resource-consolidation-content.md @@ -60,6 +60,18 @@ Use this pattern for tasks that are not cost effective if they run in their own This pattern might not be suitable for tasks that perform critical fault-tolerant operations, or tasks that process highly sensitive or private data and require their own security context. These tasks should run in their own isolated environment, in a separate computational unit. +## Workload design + +An architect should evaluate how the Compute Resource Consolidation pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Cost Optimization](/azure/well-architected/cost-optimization/checklist) is focused on **sustaining and improving** your workload's **return on investment**. | This pattern maximizes the utilization of computing resources by avoiding unused provisioned capacity via aggregation of components or even whole workloads on a pooled infrastructure.

- [CO:14 Consolidation](/azure/well-architected/cost-optimization/consolidation) | +| [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | Consolidation can lead to a more homogenous compute platform, which can simplify management and observability, reduce disparate approaches to operational tasks, and reduce the amount of tooling that's required.

- [OE:07 Monitoring system](/azure/well-architected/operational-excellence/observability)
- [OE:10 Automation design](/azure/well-architected/operational-excellence/enable-automation) | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | Consolidation maximizes the utilization of computing resources by using spare node capacity and reducing the need for overprovisioning. Large (vertically scaled) compute instances are often used in the resource pool for these infrastructures.

- [PE:02 Capacity planning](/azure/well-architected/performance-efficiency/capacity-planning)
- [PE:03 Selecting services](/azure/well-architected/performance-efficiency/capacity-planning) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Application platform choices This pattern can be achieved in different ways, depending on the compute service you use. See the following example services: From a5e80451341b636319143a10963ad74cc1e78de6 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 18:40:25 +0000 Subject: [PATCH 13/27] WAF + CQRS pattern --- docs/patterns/cqrs-content.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/patterns/cqrs-content.md b/docs/patterns/cqrs-content.md index 4bf5d4356c..eee52ac2ff 100644 --- a/docs/patterns/cqrs-content.md +++ b/docs/patterns/cqrs-content.md @@ -84,6 +84,16 @@ This pattern isn't recommended when: Consider applying CQRS to limited sections of your system where it will be most valuable. +## Workload design + +An architect should evaluate how the CQRS pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | The separation of read and write operations in high read-to-write workloads enables targeted performance and scaling optimizations for each operation's specific purpose.

- [PE:05 Scaling and partitioning](/azure/well-architected/performance-efficiency/scale-partition)
- [PE:08 Data performance](/azure/well-architected/performance-efficiency/optimize-data-performance) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Event Sourcing and CQRS pattern The CQRS pattern is often used along with the Event Sourcing pattern. CQRS-based systems use separate read and write data models, each tailored to relevant tasks and often located in physically separate stores. When used with the [Event Sourcing pattern](./event-sourcing.yml), the store of events is the write model, and is the official source of information. The read model of a CQRS-based system provides materialized views of the data, typically as highly denormalized views. These views are tailored to the interfaces and display requirements of the application, which helps to maximize both display and query performance. From 10dacf190696b012d0a688b86a7310e88451e586 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 18:43:41 +0000 Subject: [PATCH 14/27] WAF + Deployment Stamps pattern --- docs/patterns/deployment-stamp-content.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/patterns/deployment-stamp-content.md b/docs/patterns/deployment-stamp-content.md index b68935353f..4b4cd7081b 100644 --- a/docs/patterns/deployment-stamp-content.md +++ b/docs/patterns/deployment-stamp-content.md @@ -113,6 +113,17 @@ This pattern is not suitable for: - Solutions in which only some components need to be scaled, but not others. For example, consider whether your solution could be scaled by [sharding the data store](sharding.yml) rather than deploying a new copy of all of the solution components. - Solutions comprised solely of static content, such as a front-end JavaScript application. Consider storing such content in a [storage account](/azure/storage/blobs/storage-blob-static-website) and using [Azure CDN](/azure/storage/blobs/storage-blob-static-website). +## Workload design + +An architect should evaluate how the Deployment Stamps pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | This pattern supports immutable infrastructure goals, advanced deployment models, and can facilitate safe deployment practices.

- [OE:05 Infrastructure as code](/azure/well-architected/operational-excellence/infrastructure-as-code-design)
- [OE:11 Safe deployment practices](/azure/well-architected/operational-excellence/safe-deployments) | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | This pattern often aligns to the defined scale units in your workload: as additional capacity is needed beyond what a single scale unit provides, an additional deployment stamp is deployed for scaling out.

- [PE:05 Scaling and partitioning](/azure/well-architected/performance-efficiency/scale-partition) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Supporting technologies - Infrastructure as code. For example, Bicep, Resource Manager templates, Azure CLI, Terraform, PowerShell, Bash. From 9dff3245256d7638b759a9793ff7b14c10de46f7 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 18:47:56 +0000 Subject: [PATCH 15/27] WAF + Event Sourcing pattern --- docs/patterns/event-sourcing-content.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/patterns/event-sourcing-content.md b/docs/patterns/event-sourcing-content.md index 3ba84b6964..37bdb52c40 100644 --- a/docs/patterns/event-sourcing-content.md +++ b/docs/patterns/event-sourcing-content.md @@ -94,6 +94,17 @@ This pattern might not be useful in the following situations: - Systems where there's only a low occurrence of conflicting updates to the underlying data. For example, systems that predominantly add data rather than updating it. +## Workload design + +An architect should evaluate how the Event Sourcing pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | Due to capturing a history of changes in complex business process, it can facilitate state reconstruction if you need to recover state stores.

- [RE:06 Data partitioning](/azure/well-architected/reliability/partition-data)
- [RE:09 Disaster recovery](/azure/well-architected/reliability/disaster-recovery) | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | This pattern, usually combined with CQRS, an appropriate domain design, and strategic snapshotting, can improve workload performance due to the atomic append-only operations and the avoidance of database locking for writes and reads.

- [PE:08 Data performance](/azure/well-architected/performance-efficiency/optimize-data-performance) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Example A conference management system needs to track the number of completed bookings for a conference. This way it can check whether there are seats still available, when a potential attendee tries to make a booking. The system could store the total number of bookings for a conference in at least two ways: From eba724001ae17dee76fc7a0749e6e08ee40fe90a Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 18:51:29 +0000 Subject: [PATCH 16/27] WAF + External Configuration Store pattern --- docs/patterns/external-configuration-store-content.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/patterns/external-configuration-store-content.md b/docs/patterns/external-configuration-store-content.md index 5e504467bb..d4ae0f4444 100644 --- a/docs/patterns/external-configuration-store-content.md +++ b/docs/patterns/external-configuration-store-content.md @@ -56,6 +56,16 @@ This pattern is useful for: - As a way to simplify administration of multiple applications, and optionally for monitoring use of configuration settings by logging some or all types of access to the configuration store. +## Workload design + +An architect should evaluate how the External Configuration Store pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | This separation of application configuration from application code supports environment-specific configuration and applies versioning to configuration values. External configuration stores are also a common place to manage feature flags to enable safe deployment practices.

- [OE:10 Automation design](/azure/well-architected/operational-excellence/enable-automation)
- [OE:11 Safe deployment practices](/azure/well-architected/operational-excellence/safe-deployments) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Custom backing store example In a Microsoft Azure hosted application, a possible choice for storing configuration information externally is to use Azure Storage. This is resilient, offers high performance, and is replicated three times with automatic failover to offer high availability. Azure Table storage provides a key/value store with the ability to use a flexible schema for the values. Azure Blob storage provides a hierarchical, container-based store that can hold any type of data in individually named blobs. From 8b3995b33c762e5c541392b67f3615e4b73eee24 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 18:56:26 +0000 Subject: [PATCH 17/27] WAF + Federated Identity pattern --- docs/patterns/federated-identity-content.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/patterns/federated-identity-content.md b/docs/patterns/federated-identity-content.md index 24abf05124..d019943f15 100644 --- a/docs/patterns/federated-identity-content.md +++ b/docs/patterns/federated-identity-content.md @@ -58,6 +58,18 @@ This pattern might not be useful in the following situations: - The application was originally built using a different authentication mechanism, perhaps with custom user stores, or doesn't have the capability to handle the negotiation standards used by claims-based technologies. Retrofitting claims-based authentication and access control into existing applications can be complex, and probably not cost effective. +## Workload design + +An architect should evaluate how the Federated Identity pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | Offloading user management and authentication shifts reliability for those components to the identity provider, which usually has a high SLO. Additionally, during workload disaster recovery, authentication components likely won't need to be addressed as part of the workload recovery plan.

- [RE:02 Critical flows](/azure/well-architected/reliability/identify-flows)
- [RE:09 Disaster recovery](/azure/well-architected/reliability/disaster-recovery) | +| [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | By externalizing user management and authentication, you can get evolved capabilities for identity-based threat detection and prevention without needing to implement these capabilities in your workload. And external identity providers use modern interoperable authentication protocols.

- [SE:02 Secured development lifecycle](/azure/well-architected/security/secure-development-lifecycle)
- [SE:10 Monitoring and threat detection](/azure/well-architected/security/monitor-threats) | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | When you offload user management and authentication, you can devote application resources to other priorities.

- [PE:03 Selecting services](/azure/well-architected/performance-efficiency/select-services) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Example An organization hosts a multi-tenant software as a service (SaaS) application in Microsoft Azure. The application includes a website that tenants can use to manage the application for their own users. The application allows tenants to access the website by using a federated identity that is generated by Active Directory Federation Services (AD FS) when a user is authenticated by that organization's own Active Directory. From dc50b41b42f995ee3c539f2b751c190780c20011 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 19:35:52 +0000 Subject: [PATCH 18/27] WAF + Gatekeeper pattern --- docs/patterns/gatekeeper-content.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/patterns/gatekeeper-content.md b/docs/patterns/gatekeeper-content.md index 73651b6036..58760daadc 100644 --- a/docs/patterns/gatekeeper-content.md +++ b/docs/patterns/gatekeeper-content.md @@ -40,6 +40,17 @@ This pattern is helpful for applications that: - perform mission-critical operations that can't be disrupted. - require request validation be performed separately from the main tasks, or to centralize this validation to simplify maintenance and administration +## Workload design + +An architect should evaluate how the Gatekeeper pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | Adding a gateway into the request flow enables you to centralize security functionality like web application firewalls, DDoS protection, bot detection, request manipulation, authentication initiation, and authorization checks.

- [SE:06 Network controls](/azure/well-architected/security/networking)
- [SE:10 Monitoring and threat detection](/azure/well-architected/security/monitor-threats) | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | This pattern is how you can implement throttling at a gateway level rather than implementing rate checks at the node level. Coordinating rate state among all nodes isn't inherently performant.

- [PE:03 Selecting services](/azure/well-architected/performance-efficiency/select-services) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Example In a cloud-hosted scenario, this pattern can be implemented by decoupling the gatekeeper role or virtual machine, from the trusted roles and services in an application. The implementation can use an internal endpoint, a queue, or storage as an intermediate communication mechanism. The figure illustrates using an internal endpoint. From e67d13bf2dbe69dee53717f804687353396d7c8e Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 19:44:02 +0000 Subject: [PATCH 19/27] WAF + Gateway Aggregation pattern --- docs/patterns/gateway-aggregation-content.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/docs/patterns/gateway-aggregation-content.md b/docs/patterns/gateway-aggregation-content.md index 9a47b77f9c..30f5252dcb 100644 --- a/docs/patterns/gateway-aggregation-content.md +++ b/docs/patterns/gateway-aggregation-content.md @@ -45,6 +45,19 @@ This pattern may not be suitable when: - You want to reduce the number of calls between a client and a single service across multiple operations. In that scenario, it may be better to add a batch operation to the service. - The client or application is located near the backend services and latency is not a significant factor. +## Workload design + +An architect should evaluate how the Gateway Aggregation pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | This topology enables you to, amoung other thing, shift transient fault handling from a distributed implementation across clients to a centralized implementation.

- [RE:07 Transient faults](/azure/well-architected/reliability/handle-transient-faults) | +| [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | This topology often reduces the number of touch points a client has with a system, which reduces the public surface area and authentication points. The aggregated backends can stay fully network-isolated from clients.

- [SE:04 Segmentation](/azure/well-architected/security/segmentation)
- [SE:08 Hardening](/azure/well-architected/security/harden-resources) | +| [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | This pattern enables backend logic to evolve independently from clients, allowing you to change the chained service implementations, or even data sources, without needing to change client touchpoints.

- [OE:04 Tools and processes](azure/well-architected/operational-excellence/tools-processes) | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | This design can incur less latency than a design in which the client establishes multiple connections. Caching in aggregation implementations minimizes calls to backend systems.

- [PE:03 Selecting services](/azure/well-architected/performance-efficiency/select-services)
- [PE:08 Data performance](/azure/well-architected/performance-efficiency/optimize-data-performance) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Example The following example illustrates how to create a simple a gateway aggregation NGINX service using Lua. From 59d6340b70b6c1e2adcd80b1014378832d135d6b Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 21:03:49 +0000 Subject: [PATCH 20/27] WAF + Gateway Offloading pattern --- docs/patterns/gateway-offloading-content.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/docs/patterns/gateway-offloading-content.md b/docs/patterns/gateway-offloading-content.md index caa0a514a3..d0179fd0af 100644 --- a/docs/patterns/gateway-offloading-content.md +++ b/docs/patterns/gateway-offloading-content.md @@ -42,6 +42,20 @@ Use this pattern when: This pattern may not be suitable if it introduces coupling across services. +## Workload design + +An architect should evaluate how the Gateway Offloading pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | Offloading this responsibility to a gateway reduces the complexity of application code on backend nodes. In some cases, offloading completely replaces functionality with a reliable platform-provided feature.

- [RE:01 Simplicity and efficiency](/azure/well-architected/reliability/simplify) | +| [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | Adding a gateway into the request flow enables you to centralize security functionality like web application firewalls and TLS connections with clients. Any offloaded functionality that's platform-provided already offers enhanced security.

- [SE:06 Network controls](/azure/well-architected/security/networking)
- [SE:08 Hardening resources](/azure/well-architected/security/harden-resources) | +| [Cost Optimization](/azure/well-architected/cost-optimization/checklist) is focused on **sustaining and improving** your workload's **return on investment**. | This pattern enables you to redirect costs from resources that would be spent per-node into the gateway implementation. Costs in the centralized processing model are frequently lower than those of the distributed model.

- [CO:14 Consolidation](/azure/well-architected/cost-optimization/consolidation) | +| [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | In this pattern, the configuration and upkeep of the offloaded functionality is from single point instead of managing it from multiple nodes.

- [OE:04 Tools and processes]/azure/well-architected/operational-excellence/tools-processes) | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | Adding an offloading gateway to the request process enables you to use less resources per-node because functionality is centralized at the gateway. You can optimize the implementation of the offloaded functionality independently of the application code. Offloaded platform-provided functionality is already likely to be highly performant.

- [PE:03 Selecting services](/azure/well-architected/performance-efficiency/select-services) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Example Using Nginx as the SSL offload appliance, the following configuration terminates an inbound SSL connection and distributes the connection to one of three upstream HTTP servers. From 03a08cc6c7465be95984fe41503d19b69485ed7b Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 21:14:32 +0000 Subject: [PATCH 21/27] WAF + Gateway Routing pattern --- docs/patterns/gateway-routing-content.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs/patterns/gateway-routing-content.md b/docs/patterns/gateway-routing-content.md index 553681a007..1113604de9 100644 --- a/docs/patterns/gateway-routing-content.md +++ b/docs/patterns/gateway-routing-content.md @@ -62,6 +62,18 @@ Use this pattern when: This pattern may not be suitable when you have a simple application that uses only one or two services. +## Workload design + +An architect should evaluate how the Gateway Routing pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | Gateway routing enables you to route traffic to only healthy nodes in your system.

- [RE:05 Redundancy](/azure/well-architected/reliability/redundancy)
- [RE:10 Health monitoring](/azure/well-architected/reliability/monitoring-alerting-strategy) | +| [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | Gateway routing enables you to decouple requests from backends, which in turn enables your backends to support advanced deployment models, platform transitions, and a single point of management for domain name resolution and encryption in transit.

- [OE:04 Tools and processes](/azure/well-architected/operational-excellence/tools-processes)
- [OE:11 Safe deployment practices](/azure/well-architected/operational-excellence/safe-deployments) | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | Gateway routing enables you to distribute traffic across nodes in your system to balance load.

- [PE:05 Scaling and partitioning](/azure/well-architected/performance-efficiency/scale-partition) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Example Using Nginx as the router, the following is a simple example configuration file for a server that routes requests for applications residing on different virtual directories to different machines at the back end. From 5155577a11b27c9fe2d91367d38f5e0d82800408 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 21:18:29 +0000 Subject: [PATCH 22/27] WAF + Geodes pattern --- docs/patterns/geodes-content.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/docs/patterns/geodes-content.md b/docs/patterns/geodes-content.md index 77e1e27d5d..ccf133a298 100644 --- a/docs/patterns/geodes-content.md +++ b/docs/patterns/geodes-content.md @@ -69,6 +69,17 @@ This pattern might not be suitable for - Situations where a legacy platform needs to be retrofitted. This pattern works for cloud-native development only, and can be difficult to retrofit. - Simple architectures and requirements, where geo-redundancy and geo-distribution aren't required or advantageous. +## Workload design + +An architect should evaluate how the Geodes pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: + +| Pillar | How this pattern supports pillar goals | +| :----- | :------------------------------------- | +| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | This pattern uses data replication to support the ideal that any client can connect to any geographical instance and by doing so it can help your workload withstand one or more regional outages.

- [RE:05 High-availability multi-region design](/well-architected/reliability/highly-available-multi-region-design)
- [RE:05 Regions and availability zones](/azure/well-architected/reliability/regions-availability-zones) | +| [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | You can use this pattern to serve your application from a region that's closest to your distributed user base. Doing so reduces latency by eliminating long-distance traffic and because you share infrastructure only among users that are currently using the same geode.

- [PE:03 Selecting services](/azure/well-architected/performance-efficiency/select-services) | + +As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. + ## Examples - Windows Active Directory implements an early variant of this pattern. Multi-primary replication means all updates and requests can in theory be served from all serviceable nodes, but Flexible Single Master Operation (FSMO) roles mean that all geodes aren't equal. From 0a3ab1702f7431985d95126a8dee1bd5f2f561d0 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 22:35:24 +0000 Subject: [PATCH 23/27] address build errors --- docs/patterns/gateway-aggregation-content.md | 2 +- docs/patterns/geodes-content.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/patterns/gateway-aggregation-content.md b/docs/patterns/gateway-aggregation-content.md index 30f5252dcb..7f8e7c4e86 100644 --- a/docs/patterns/gateway-aggregation-content.md +++ b/docs/patterns/gateway-aggregation-content.md @@ -53,7 +53,7 @@ An architect should evaluate how the Gateway Aggregation pattern can be used in | :----- | :------------------------------------- | | [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | This topology enables you to, amoung other thing, shift transient fault handling from a distributed implementation across clients to a centralized implementation.

- [RE:07 Transient faults](/azure/well-architected/reliability/handle-transient-faults) | | [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | This topology often reduces the number of touch points a client has with a system, which reduces the public surface area and authentication points. The aggregated backends can stay fully network-isolated from clients.

- [SE:04 Segmentation](/azure/well-architected/security/segmentation)
- [SE:08 Hardening](/azure/well-architected/security/harden-resources) | -| [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | This pattern enables backend logic to evolve independently from clients, allowing you to change the chained service implementations, or even data sources, without needing to change client touchpoints.

- [OE:04 Tools and processes](azure/well-architected/operational-excellence/tools-processes) | +| [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | This pattern enables backend logic to evolve independently from clients, allowing you to change the chained service implementations, or even data sources, without needing to change client touchpoints.

- [OE:04 Tools and processes](/azure/well-architected/operational-excellence/tools-processes) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | This design can incur less latency than a design in which the client establishes multiple connections. Caching in aggregation implementations minimizes calls to backend systems.

- [PE:03 Selecting services](/azure/well-architected/performance-efficiency/select-services)
- [PE:08 Data performance](/azure/well-architected/performance-efficiency/optimize-data-performance) | As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. diff --git a/docs/patterns/geodes-content.md b/docs/patterns/geodes-content.md index ccf133a298..5374780438 100644 --- a/docs/patterns/geodes-content.md +++ b/docs/patterns/geodes-content.md @@ -75,7 +75,7 @@ An architect should evaluate how the Geodes pattern can be used in their workloa | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | -| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | This pattern uses data replication to support the ideal that any client can connect to any geographical instance and by doing so it can help your workload withstand one or more regional outages.

- [RE:05 High-availability multi-region design](/well-architected/reliability/highly-available-multi-region-design)
- [RE:05 Regions and availability zones](/azure/well-architected/reliability/regions-availability-zones) | +| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | This pattern uses data replication to support the ideal that any client can connect to any geographical instance and by doing so it can help your workload withstand one or more regional outages.

- [RE:05 High-availability multi-region design](/azure/well-architected/reliability/highly-available-multi-region-design)
- [RE:05 Regions and availability zones](/azure/well-architected/reliability/regions-availability-zones) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | You can use this pattern to serve your application from a region that's closest to your distributed user base. Doing so reduces latency by eliminating long-distance traffic and because you share infrastructure only among users that are currently using the same geode.

- [PE:03 Selecting services](/azure/well-architected/performance-efficiency/select-services) | As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. From 226c40e50e7b0fcdef589d667d00e7fba9b2814e Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 22:38:30 +0000 Subject: [PATCH 24/27] typos --- docs/patterns/ambassador-content.md | 4 ++-- docs/patterns/anti-corruption-layer-content.md | 4 ++-- docs/patterns/async-request-reply-content.md | 4 ++-- docs/patterns/backends-for-frontends-content.md | 4 ++-- docs/patterns/bulkhead-content.md | 4 ++-- docs/patterns/cache-aside-content.md | 4 ++-- docs/patterns/choreography-content.md | 4 ++-- docs/patterns/circuit-breaker-content.md | 4 ++-- docs/patterns/claim-check-content.md | 4 ++-- docs/patterns/compensating-transaction-content.md | 4 ++-- docs/patterns/competing-consumers-content.md | 4 ++-- docs/patterns/compute-resource-consolidation-content.md | 4 ++-- docs/patterns/cqrs-content.md | 4 ++-- docs/patterns/deployment-stamp-content.md | 4 ++-- docs/patterns/event-sourcing-content.md | 4 ++-- docs/patterns/external-configuration-store-content.md | 4 ++-- docs/patterns/federated-identity-content.md | 4 ++-- docs/patterns/gatekeeper-content.md | 4 ++-- docs/patterns/gateway-aggregation-content.md | 4 ++-- docs/patterns/gateway-offloading-content.md | 4 ++-- docs/patterns/gateway-routing-content.md | 4 ++-- docs/patterns/geodes-content.md | 4 ++-- 22 files changed, 44 insertions(+), 44 deletions(-) diff --git a/docs/patterns/ambassador-content.md b/docs/patterns/ambassador-content.md index dee66359ae..89c1371fcf 100644 --- a/docs/patterns/ambassador-content.md +++ b/docs/patterns/ambassador-content.md @@ -42,14 +42,14 @@ This pattern may not be suitable: ## Workload design -An architect should evaluate how the Ambassador pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Ambassador pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | | [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | The network communications mediation point facilitated by this pattern provides an opportunity to add reliability patterns to network communication, such as retry or buffering.

- [RE:07 Self-preservation](/azure/well-architected/reliability/self-preservation) | | [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | This pattern provides an opportunity to augment security on network communications that could not have been handled by the client directly.

- [SE:06 Network controls](/azure/well-architected/security/networking)
- [SE:07 Encryption](/azure/well-architected/security/encryption) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Example diff --git a/docs/patterns/anti-corruption-layer-content.md b/docs/patterns/anti-corruption-layer-content.md index ed44351fc0..ef37cce605 100644 --- a/docs/patterns/anti-corruption-layer-content.md +++ b/docs/patterns/anti-corruption-layer-content.md @@ -41,13 +41,13 @@ This pattern may not be suitable if there are no significant semantic difference ## Workload design -An architect should evaluate how the Anti-corruption Layer pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Anti-corruption Layer pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | | [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | This pattern helps ensure that new component design remains uninfluenced by legacy implementations that might have different data models or business rules when you integrate with these legacy systems and it can reduce technical debt in new components while still supporting existing components.

- [OE:04 Tools and processes](/azure/well-architected/operational-excellence/tools-processes) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Related resources diff --git a/docs/patterns/async-request-reply-content.md b/docs/patterns/async-request-reply-content.md index fc6bae8bb5..c5f8818413 100644 --- a/docs/patterns/async-request-reply-content.md +++ b/docs/patterns/async-request-reply-content.md @@ -94,13 +94,13 @@ This pattern might not be suitable when: ## Workload design -An architect should evaluate how the Asynchronous Request-Reply pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Asynchronous Request-Reply pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | Decoupling the request and reply phases of interactions for processes that don't need immediate answers improves the responsiveness and scalability of systems. As an asynchronous appproach, you can maximize concurrency on the server side and schedule work to be completed as capacity allows.

- [PE:05 Scaling and partitioning](/azure/well-architected/performance-efficiency/scale-partition)
- [PE:07 Code and infrastructure](/azure/well-architected/performance-efficiency/optimize-code-infrastructure) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Example diff --git a/docs/patterns/backends-for-frontends-content.md b/docs/patterns/backends-for-frontends-content.md index 8c0a3213af..04b8092018 100644 --- a/docs/patterns/backends-for-frontends-content.md +++ b/docs/patterns/backends-for-frontends-content.md @@ -47,7 +47,7 @@ This pattern may not be suitable: ## Workload design -An architect should evaluate how the Backends for Frontends pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Backends for Frontends pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | @@ -55,7 +55,7 @@ An architect should evaluate how the Backends for Frontends pattern can be used | [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | Because of service separation introduced in this pattern, the security and authorization in the service layer that supports one client can be tailored to the functionality required by that client, potentially reducing the surface area of an API and lateral movement among different backends that might expose different capabilities.

- [SE:04 Segmentation](/azure/well-architected/security/segmentation)
- [SE:08 Hardening resources](/azure/well-architected/security/harden-resources) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | The backend separation enables you to optimize in ways that might not be possible with a shared service layer. When you handle individual clients differently, you can optimize performance for a specific client's constraints and functionality.

- [PE:02 Capacity planning](/azure/well-architected/performance-efficiency/capacity-planning)
- [PE:09 Critical flows](/azure/well-architected/performance-efficiency/prioritize-critical-flows) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Next steps diff --git a/docs/patterns/bulkhead-content.md b/docs/patterns/bulkhead-content.md index a0662046cb..fa3720be22 100644 --- a/docs/patterns/bulkhead-content.md +++ b/docs/patterns/bulkhead-content.md @@ -54,7 +54,7 @@ This pattern may not be suitable when: ## Workload design -An architect should evaluate how the Bulkhead pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Bulkhead pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | @@ -62,7 +62,7 @@ An architect should evaluate how the Bulkhead pattern can be used in their workl | [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | The segmentation between components helps constrain security incidents to the compromised bulkhead.

- [SE:04 Segmentation](/azure/well-architected/security/segmentation) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | Each bulkhead can be individually scalable to efficiently meet the needs of the task that's encapsulated in the bulkhead.

- [PE:02 Capacity planning](/azure/well-architected/performance-efficiency/capacity-planning)
- [PE:05 Scaling and partitioning](/azure/well-architected/performance-efficiency/scale-partition) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Example diff --git a/docs/patterns/cache-aside-content.md b/docs/patterns/cache-aside-content.md index 11d1bc44af..47712100fe 100644 --- a/docs/patterns/cache-aside-content.md +++ b/docs/patterns/cache-aside-content.md @@ -46,14 +46,14 @@ This pattern might not be suitable: ## Workload design -An architect should evaluate how the Cache-Aside pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Cache-Aside pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | | [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | Caching creates data replication and, in limited ways, can be used to preserve the availability of frequently accessed data if the origin data store is temporarily unavailable. Additionally, if there's a malfunction in the cache, the workload can fall back to the origin data store.

- [RE:05 Redumdancy](/azure/well-architected/reliability/redundancy) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | Better performance in your workload can be obtained when using a cache for read-heavy data that doesn't change often and your workload is designed to tolerate a certain amount of staleness.

- [PE:08 Data performance](/azure/well-architected/performance-efficiency/optimize-data-performance)
- [PE:12 Continuous performance optimization](/azure/well-architected/performance-efficiency/continuous-performance-optimize) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Example diff --git a/docs/patterns/choreography-content.md b/docs/patterns/choreography-content.md index 33835e10ef..c3c72dc7aa 100644 --- a/docs/patterns/choreography-content.md +++ b/docs/patterns/choreography-content.md @@ -48,14 +48,14 @@ Each service isn't only responsible for the resiliency of its operation but also ## Workload design -An architect should evaluate how the Choreography pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Choreography pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | | [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | Because the distributed components in this pattern are autonomous and designed to be replaceable, you can modify the workload with less overall change to the system.

- [OE:04 Tools and processes](/azure/well-architected/operational-excellence/tools-processes) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | This pattern provides an alternative when performance bottlenecks occur in a centralized orchestration topology.

- [PE:02 Capacity planning](/azure/well-architected/performance-efficiency/capacity-planning)
- [PE:05 Scaling and partitioning](/azure/well-architected/performance-efficiency/scale-partition) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Example diff --git a/docs/patterns/circuit-breaker-content.md b/docs/patterns/circuit-breaker-content.md index 61ee008b4b..227361e131 100644 --- a/docs/patterns/circuit-breaker-content.md +++ b/docs/patterns/circuit-breaker-content.md @@ -80,14 +80,14 @@ This pattern isn't recommended: ## Workload design -An architect should evaluate how the Circuit Breaker pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Circuit Breaker pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | | [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | This pattern prevents overloading a faulting dependency. You can also use this pattern to trigger graceful degradation in the workload. Circuit breakers are often coupled with automatic recovery to provide both self-preservation and self-healing.

- [RE:03 Failure mode analysis](/azure/well-architected/reliability/failure-mode-analysis)
- [RE:07 Transient faults](/azure/well-architected/reliability/handle-transient-faults)
- [RE:07 Self-preservation](/azure/well-architected/reliability/self-preservation) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | This pattern avoids the retry-on-error approach which can lead to excessive resource utilization during dependency recovery and can also overload performance on a dependency that's attempting recovery.

- [PE:07 Code and infrastructure](/azure/well-architected/performance-efficiency/optimize-code-infrastructure)
- [PE:11 Live-issues responses](/azure/well-architected/performance-efficiency/respond-live-performance-issues) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Example diff --git a/docs/patterns/claim-check-content.md b/docs/patterns/claim-check-content.md index c2914e1b15..3d5f13bff0 100644 --- a/docs/patterns/claim-check-content.md +++ b/docs/patterns/claim-check-content.md @@ -37,7 +37,7 @@ The pattern can also be used if the payload should be accessed only by services ## Workload design -An architect should evaluate how the Claim-Check pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Claim-Check pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | @@ -46,7 +46,7 @@ An architect should evaluate how the Claim-Check pattern can be used in their wo | [Cost Optimization](/azure/well-architected/cost-optimization/checklist) is focused on **sustaining and improving** your workload's **return on investment**. | Messaging systems often impose limits on message size, and increased size limits is often a premium feature. Reducing the size of message bodies might enable you to use a cheaper messaging solution.

- [CO:07 Component costs](/azure/well-architected/cost-optimization/optimize-component-costs)
- [CO:09 Flow costs](/azure/well-architected/cost-optimization/optimize-flow-costs) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | This pattern improves the efficiency and performance of message publishers, subscribers, and the message bus itself when the system handles large data payloads. It works by decreasing the size of messages and ensuring that consumers retrieve payload data only if necessary and at an opportune time.

- [PE:05 Scaling and partitioning](/azure/well-architected/performance-efficiency/scale-partition)
- [PE:12 Continuous performance optimization](/azure/well-architected/performance-efficiency/continuous-performance-optimize) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Examples diff --git a/docs/patterns/compensating-transaction-content.md b/docs/patterns/compensating-transaction-content.md index e085cc6a0a..d243d4c48c 100644 --- a/docs/patterns/compensating-transaction-content.md +++ b/docs/patterns/compensating-transaction-content.md @@ -60,13 +60,13 @@ Use this pattern only for operations that must be undone if they fail. If possib ## Workload design -An architect should evaluate how the Compensating Transaction pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Compensating Transaction pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | | [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | Compensation actions address malfunctions in critical workload paths by using processes like directly rolling back data changes, breaking transaction locks, or even executing native system behavior to reverse the effect.

- [RE:02 Critical flows](/azure/well-architected/reliability/identify-flows)
- [RE:09 Disaster recovery](/azure/well-architected/reliability/disaster-recovery) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Example diff --git a/docs/patterns/competing-consumers-content.md b/docs/patterns/competing-consumers-content.md index 60303cdf7a..361ce81d73 100644 --- a/docs/patterns/competing-consumers-content.md +++ b/docs/patterns/competing-consumers-content.md @@ -66,7 +66,7 @@ This pattern might not be useful when: ## Workload design -An architect should evaluate how the Competing Consumers pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Competing Consumers pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | @@ -74,7 +74,7 @@ An architect should evaluate how the Competing Consumers pattern can be used in | [Cost Optimization](/azure/well-architected/cost-optimization/checklist) is focused on **sustaining and improving** your workload's **return on investment**. | This pattern can help you optimize costs by enabling scaling that's based on queue depth, down to zero when the queue is empty. It can also optimize costs by enabling you to limit the maximum number of concurrent consumer instances.

- [CO:05 Rate optimization](/azure/well-architected/cost-optimization/get-best-rates)
- [CO:07 Component costs](/azure/well-architected/cost-optimization/optimize-component-costs) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | Distributing load across all consumer nodes increases utilization and dynamic scaling based on queue depth minimize overprovisioning.

- [PE:05 Scaling and partitioning](/azure/well-architected/performance-efficiency/scale-partition)
- [PE:07 Code and infrastructure](/azure/well-architected/performance-efficiency/optimize-code-infrastructure) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Example diff --git a/docs/patterns/compute-resource-consolidation-content.md b/docs/patterns/compute-resource-consolidation-content.md index 6cb4da0152..6e4101d06c 100644 --- a/docs/patterns/compute-resource-consolidation-content.md +++ b/docs/patterns/compute-resource-consolidation-content.md @@ -62,7 +62,7 @@ This pattern might not be suitable for tasks that perform critical fault-toleran ## Workload design -An architect should evaluate how the Compute Resource Consolidation pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Compute Resource Consolidation pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | @@ -70,7 +70,7 @@ An architect should evaluate how the Compute Resource Consolidation pattern can | [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | Consolidation can lead to a more homogenous compute platform, which can simplify management and observability, reduce disparate approaches to operational tasks, and reduce the amount of tooling that's required.

- [OE:07 Monitoring system](/azure/well-architected/operational-excellence/observability)
- [OE:10 Automation design](/azure/well-architected/operational-excellence/enable-automation) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | Consolidation maximizes the utilization of computing resources by using spare node capacity and reducing the need for overprovisioning. Large (vertically scaled) compute instances are often used in the resource pool for these infrastructures.

- [PE:02 Capacity planning](/azure/well-architected/performance-efficiency/capacity-planning)
- [PE:03 Selecting services](/azure/well-architected/performance-efficiency/capacity-planning) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Application platform choices diff --git a/docs/patterns/cqrs-content.md b/docs/patterns/cqrs-content.md index eee52ac2ff..ce875aedce 100644 --- a/docs/patterns/cqrs-content.md +++ b/docs/patterns/cqrs-content.md @@ -86,13 +86,13 @@ Consider applying CQRS to limited sections of your system where it will be most ## Workload design -An architect should evaluate how the CQRS pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the CQRS pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | The separation of read and write operations in high read-to-write workloads enables targeted performance and scaling optimizations for each operation's specific purpose.

- [PE:05 Scaling and partitioning](/azure/well-architected/performance-efficiency/scale-partition)
- [PE:08 Data performance](/azure/well-architected/performance-efficiency/optimize-data-performance) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Event Sourcing and CQRS pattern diff --git a/docs/patterns/deployment-stamp-content.md b/docs/patterns/deployment-stamp-content.md index 4b4cd7081b..3c3613d94b 100644 --- a/docs/patterns/deployment-stamp-content.md +++ b/docs/patterns/deployment-stamp-content.md @@ -115,14 +115,14 @@ This pattern is not suitable for: ## Workload design -An architect should evaluate how the Deployment Stamps pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Deployment Stamps pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | | [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | This pattern supports immutable infrastructure goals, advanced deployment models, and can facilitate safe deployment practices.

- [OE:05 Infrastructure as code](/azure/well-architected/operational-excellence/infrastructure-as-code-design)
- [OE:11 Safe deployment practices](/azure/well-architected/operational-excellence/safe-deployments) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | This pattern often aligns to the defined scale units in your workload: as additional capacity is needed beyond what a single scale unit provides, an additional deployment stamp is deployed for scaling out.

- [PE:05 Scaling and partitioning](/azure/well-architected/performance-efficiency/scale-partition) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Supporting technologies diff --git a/docs/patterns/event-sourcing-content.md b/docs/patterns/event-sourcing-content.md index 37bdb52c40..191f6db19c 100644 --- a/docs/patterns/event-sourcing-content.md +++ b/docs/patterns/event-sourcing-content.md @@ -96,14 +96,14 @@ This pattern might not be useful in the following situations: ## Workload design -An architect should evaluate how the Event Sourcing pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Event Sourcing pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | | [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | Due to capturing a history of changes in complex business process, it can facilitate state reconstruction if you need to recover state stores.

- [RE:06 Data partitioning](/azure/well-architected/reliability/partition-data)
- [RE:09 Disaster recovery](/azure/well-architected/reliability/disaster-recovery) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | This pattern, usually combined with CQRS, an appropriate domain design, and strategic snapshotting, can improve workload performance due to the atomic append-only operations and the avoidance of database locking for writes and reads.

- [PE:08 Data performance](/azure/well-architected/performance-efficiency/optimize-data-performance) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Example diff --git a/docs/patterns/external-configuration-store-content.md b/docs/patterns/external-configuration-store-content.md index d4ae0f4444..2a3069e3b8 100644 --- a/docs/patterns/external-configuration-store-content.md +++ b/docs/patterns/external-configuration-store-content.md @@ -58,13 +58,13 @@ This pattern is useful for: ## Workload design -An architect should evaluate how the External Configuration Store pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the External Configuration Store pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | | [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | This separation of application configuration from application code supports environment-specific configuration and applies versioning to configuration values. External configuration stores are also a common place to manage feature flags to enable safe deployment practices.

- [OE:10 Automation design](/azure/well-architected/operational-excellence/enable-automation)
- [OE:11 Safe deployment practices](/azure/well-architected/operational-excellence/safe-deployments) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Custom backing store example diff --git a/docs/patterns/federated-identity-content.md b/docs/patterns/federated-identity-content.md index d019943f15..8cd9d67c9c 100644 --- a/docs/patterns/federated-identity-content.md +++ b/docs/patterns/federated-identity-content.md @@ -60,7 +60,7 @@ This pattern might not be useful in the following situations: ## Workload design -An architect should evaluate how the Federated Identity pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Federated Identity pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | @@ -68,7 +68,7 @@ An architect should evaluate how the Federated Identity pattern can be used in t | [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | By externalizing user management and authentication, you can get evolved capabilities for identity-based threat detection and prevention without needing to implement these capabilities in your workload. And external identity providers use modern interoperable authentication protocols.

- [SE:02 Secured development lifecycle](/azure/well-architected/security/secure-development-lifecycle)
- [SE:10 Monitoring and threat detection](/azure/well-architected/security/monitor-threats) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | When you offload user management and authentication, you can devote application resources to other priorities.

- [PE:03 Selecting services](/azure/well-architected/performance-efficiency/select-services) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Example diff --git a/docs/patterns/gatekeeper-content.md b/docs/patterns/gatekeeper-content.md index 58760daadc..09c2b22931 100644 --- a/docs/patterns/gatekeeper-content.md +++ b/docs/patterns/gatekeeper-content.md @@ -42,14 +42,14 @@ This pattern is helpful for applications that: ## Workload design -An architect should evaluate how the Gatekeeper pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Gatekeeper pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | | [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | Adding a gateway into the request flow enables you to centralize security functionality like web application firewalls, DDoS protection, bot detection, request manipulation, authentication initiation, and authorization checks.

- [SE:06 Network controls](/azure/well-architected/security/networking)
- [SE:10 Monitoring and threat detection](/azure/well-architected/security/monitor-threats) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | This pattern is how you can implement throttling at a gateway level rather than implementing rate checks at the node level. Coordinating rate state among all nodes isn't inherently performant.

- [PE:03 Selecting services](/azure/well-architected/performance-efficiency/select-services) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Example diff --git a/docs/patterns/gateway-aggregation-content.md b/docs/patterns/gateway-aggregation-content.md index 7f8e7c4e86..323f280179 100644 --- a/docs/patterns/gateway-aggregation-content.md +++ b/docs/patterns/gateway-aggregation-content.md @@ -47,7 +47,7 @@ This pattern may not be suitable when: ## Workload design -An architect should evaluate how the Gateway Aggregation pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Gateway Aggregation pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | @@ -56,7 +56,7 @@ An architect should evaluate how the Gateway Aggregation pattern can be used in | [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | This pattern enables backend logic to evolve independently from clients, allowing you to change the chained service implementations, or even data sources, without needing to change client touchpoints.

- [OE:04 Tools and processes](/azure/well-architected/operational-excellence/tools-processes) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | This design can incur less latency than a design in which the client establishes multiple connections. Caching in aggregation implementations minimizes calls to backend systems.

- [PE:03 Selecting services](/azure/well-architected/performance-efficiency/select-services)
- [PE:08 Data performance](/azure/well-architected/performance-efficiency/optimize-data-performance) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Example diff --git a/docs/patterns/gateway-offloading-content.md b/docs/patterns/gateway-offloading-content.md index d0179fd0af..7b8a154d3d 100644 --- a/docs/patterns/gateway-offloading-content.md +++ b/docs/patterns/gateway-offloading-content.md @@ -44,7 +44,7 @@ This pattern may not be suitable if it introduces coupling across services. ## Workload design -An architect should evaluate how the Gateway Offloading pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Gateway Offloading pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | @@ -54,7 +54,7 @@ An architect should evaluate how the Gateway Offloading pattern can be used in t | [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | In this pattern, the configuration and upkeep of the offloaded functionality is from single point instead of managing it from multiple nodes.

- [OE:04 Tools and processes]/azure/well-architected/operational-excellence/tools-processes) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | Adding an offloading gateway to the request process enables you to use less resources per-node because functionality is centralized at the gateway. You can optimize the implementation of the offloaded functionality independently of the application code. Offloaded platform-provided functionality is already likely to be highly performant.

- [PE:03 Selecting services](/azure/well-architected/performance-efficiency/select-services) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Example diff --git a/docs/patterns/gateway-routing-content.md b/docs/patterns/gateway-routing-content.md index 1113604de9..115a327b21 100644 --- a/docs/patterns/gateway-routing-content.md +++ b/docs/patterns/gateway-routing-content.md @@ -64,7 +64,7 @@ This pattern may not be suitable when you have a simple application that uses on ## Workload design -An architect should evaluate how the Gateway Routing pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Gateway Routing pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | @@ -72,7 +72,7 @@ An architect should evaluate how the Gateway Routing pattern can be used in thei | [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | Gateway routing enables you to decouple requests from backends, which in turn enables your backends to support advanced deployment models, platform transitions, and a single point of management for domain name resolution and encryption in transit.

- [OE:04 Tools and processes](/azure/well-architected/operational-excellence/tools-processes)
- [OE:11 Safe deployment practices](/azure/well-architected/operational-excellence/safe-deployments) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | Gateway routing enables you to distribute traffic across nodes in your system to balance load.

- [PE:05 Scaling and partitioning](/azure/well-architected/performance-efficiency/scale-partition) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Example diff --git a/docs/patterns/geodes-content.md b/docs/patterns/geodes-content.md index 5374780438..0be37a35bd 100644 --- a/docs/patterns/geodes-content.md +++ b/docs/patterns/geodes-content.md @@ -71,14 +71,14 @@ This pattern might not be suitable for ## Workload design -An architect should evaluate how the Geodes pattern can be used in their workloads's design to addresses the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: +An architect should evaluate how the Geodes pattern can be used in their workloads's design to address the goals and principles covered in the [Azure Well-Architected Framework pillars](/azure/well-architected/pillars). For example: | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | | [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | This pattern uses data replication to support the ideal that any client can connect to any geographical instance and by doing so it can help your workload withstand one or more regional outages.

- [RE:05 High-availability multi-region design](/azure/well-architected/reliability/highly-available-multi-region-design)
- [RE:05 Regions and availability zones](/azure/well-architected/reliability/regions-availability-zones) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | You can use this pattern to serve your application from a region that's closest to your distributed user base. Doing so reduces latency by eliminating long-distance traffic and because you share infrastructure only among users that are currently using the same geode.

- [PE:03 Selecting services](/azure/well-architected/performance-efficiency/select-services) | -As with any design decision, consider any tradeoffs against the goals of the other pillars that might introduced with this pattern. +As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern. ## Examples From 2b192fd8a10468534ab364865bc571e2135f9778 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 22:44:45 +0000 Subject: [PATCH 25/27] acrolinx --- docs/patterns/ambassador-content.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/patterns/ambassador-content.md b/docs/patterns/ambassador-content.md index 89c1371fcf..73894aa2a6 100644 --- a/docs/patterns/ambassador-content.md +++ b/docs/patterns/ambassador-content.md @@ -1,6 +1,6 @@ Create helper services that send network requests on behalf of a consumer service or application. An ambassador service can be thought of as an out-of-process proxy that is co-located with the client. -This pattern can be useful for offloading common client connectivity tasks such as monitoring, logging, routing, security (such as TLS), and [resiliency patterns](/azure/architecture/framework/resiliency/reliability-patterns) in a language agnostic way. It is often used with legacy applications, or other applications that are difficult to modify, in order to extend their networking capabilities. It can also enable a specialized team to implement those features. +This pattern can be useful for offloading common client connectivity tasks such as monitoring, logging, routing, security (such as TLS), and [resiliency patterns](/azure/well-architected/reliability/design-patterns) in a language agnostic way. It's often used with legacy applications, or other applications that are difficult to modify, in order to extend their networking capabilities. It can also enable a specialized team to implement those features. ## Context and problem @@ -23,7 +23,7 @@ Ambassador services can be deployed as a [sidecar](./sidecar.yml) to accompany t - The proxy adds some latency overhead. Consider whether a client library, invoked directly by the application, is a better approach. - Consider the possible impact of including generalized features in the proxy. For example, the ambassador could handle retries, but that might not be safe unless all operations are idempotent. - Consider a mechanism to allow the client to pass some context to the proxy, as well as back to the client. For example, include HTTP request headers to opt out of retry or specify the maximum number of times to retry. -- Consider how you will package and deploy the proxy. +- Consider how you'll package and deploy the proxy. - Consider whether to use a single shared instance for all clients or an instance for each client. ## When to use this pattern @@ -36,9 +36,9 @@ Use this pattern when you: This pattern may not be suitable: -- When network request latency is critical. A proxy will introduce some overhead, although minimal, and in some cases this may affect the application. +- When network request latency is critical. A proxy introduces some overhead, although minimal, and in some cases this may affect the application. - When client connectivity features are consumed by a single language. In that case, a better option might be a client library that is distributed to the development teams as a package. -- When connectivity features cannot be generalized and require deeper integration with the client application. +- When connectivity features can't be generalized and require deeper integration with the client application. ## Workload design From 3407172e190795619883d14cac9e29e5600920f9 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 22:48:23 +0000 Subject: [PATCH 26/27] another acrolinx item --- docs/patterns/gateway-aggregation-content.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/patterns/gateway-aggregation-content.md b/docs/patterns/gateway-aggregation-content.md index 323f280179..0fd2c1e701 100644 --- a/docs/patterns/gateway-aggregation-content.md +++ b/docs/patterns/gateway-aggregation-content.md @@ -26,7 +26,7 @@ In the following diagram, the application sends a request to the gateway (1). Th - The gateway may introduce a bottleneck. Ensure the gateway has adequate performance to handle load and can be scaled to meet your anticipated growth. - Perform load testing against the gateway to ensure you don't introduce cascading failures for services. - Implement a resilient design, using techniques such as [bulkheads][bulkhead], [circuit breaking][circuit-breaker], [retry][retry], and timeouts. -- If one or more service calls takes too long, it may be acceptable to timeout and return a partial set of data. Consider how your application will handle this scenario. +- If one or more service calls takes too long, it may be acceptable to time out and return a partial set of data. Consider how your application will handle this scenario. - Use asynchronous I/O to ensure that a delay at the backend doesn't cause performance issues in the application. - Implement distributed tracing using correlation IDs to track each individual call. - Monitor request metrics and response sizes. @@ -43,7 +43,7 @@ Use this pattern when: This pattern may not be suitable when: - You want to reduce the number of calls between a client and a single service across multiple operations. In that scenario, it may be better to add a batch operation to the service. -- The client or application is located near the backend services and latency is not a significant factor. +- The client or application is located near the backend services and latency isn't a significant factor. ## Workload design @@ -51,7 +51,7 @@ An architect should evaluate how the Gateway Aggregation pattern can be used in | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | -| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | This topology enables you to, amoung other thing, shift transient fault handling from a distributed implementation across clients to a centralized implementation.

- [RE:07 Transient faults](/azure/well-architected/reliability/handle-transient-faults) | +| [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | This topology enables you to, among other things, shift transient fault handling from a distributed implementation across clients to a centralized implementation.

- [RE:07 Transient faults](/azure/well-architected/reliability/handle-transient-faults) | | [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | This topology often reduces the number of touch points a client has with a system, which reduces the public surface area and authentication points. The aggregated backends can stay fully network-isolated from clients.

- [SE:04 Segmentation](/azure/well-architected/security/segmentation)
- [SE:08 Hardening](/azure/well-architected/security/harden-resources) | | [Operational Excellence](/azure/well-architected/operational-excellence/checklist) helps deliver **workload quality** through **standardized processes** and team cohesion. | This pattern enables backend logic to evolve independently from clients, allowing you to change the chained service implementations, or even data sources, without needing to change client touchpoints.

- [OE:04 Tools and processes](/azure/well-architected/operational-excellence/tools-processes) | | [Performance Efficiency](/azure/well-architected/performance-efficiency/checklist) helps your workload **efficiently meet demands** through optimizations in scaling, data, code. | This design can incur less latency than a design in which the client establishes multiple connections. Caching in aggregation implementations minimizes calls to backend systems.

- [PE:03 Selecting services](/azure/well-architected/performance-efficiency/select-services)
- [PE:08 Data performance](/azure/well-architected/performance-efficiency/optimize-data-performance) | From 3a96405c51f29136bf68be7f26c853e911c688a3 Mon Sep 17 00:00:00 2001 From: Chad Kittel Date: Tue, 13 Feb 2024 22:55:31 +0000 Subject: [PATCH 27/27] going for 80 --- docs/patterns/ambassador-content.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/patterns/ambassador-content.md b/docs/patterns/ambassador-content.md index 73894aa2a6..9ffc234dfa 100644 --- a/docs/patterns/ambassador-content.md +++ b/docs/patterns/ambassador-content.md @@ -22,7 +22,7 @@ Ambassador services can be deployed as a [sidecar](./sidecar.yml) to accompany t - The proxy adds some latency overhead. Consider whether a client library, invoked directly by the application, is a better approach. - Consider the possible impact of including generalized features in the proxy. For example, the ambassador could handle retries, but that might not be safe unless all operations are idempotent. -- Consider a mechanism to allow the client to pass some context to the proxy, as well as back to the client. For example, include HTTP request headers to opt out of retry or specify the maximum number of times to retry. +- Consider a mechanism to allow the client to pass some context to the proxy, and back to the client. For example, include HTTP request headers to opt out of retry or specify the maximum number of times to retry. - Consider how you'll package and deploy the proxy. - Consider whether to use a single shared instance for all clients or an instance for each client. @@ -47,7 +47,7 @@ An architect should evaluate how the Ambassador pattern can be used in their wor | Pillar | How this pattern supports pillar goals | | :----- | :------------------------------------- | | [Reliability](/azure/well-architected/reliability/checklist) design decisions help your workload become **resilient** to malfunction and to ensure that it **recovers** to a fully functioning state after a failure occurs. | The network communications mediation point facilitated by this pattern provides an opportunity to add reliability patterns to network communication, such as retry or buffering.

- [RE:07 Self-preservation](/azure/well-architected/reliability/self-preservation) | -| [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | This pattern provides an opportunity to augment security on network communications that could not have been handled by the client directly.

- [SE:06 Network controls](/azure/well-architected/security/networking)
- [SE:07 Encryption](/azure/well-architected/security/encryption) | +| [Security](/azure/well-architected/security/checklist) design decisions help ensure the **confidentiality**, **integrity**, and **availability** of your workload's data and systems. | This pattern provides an opportunity to augment security on network communications that couldn't have been handled by the client directly.

- [SE:06 Network controls](/azure/well-architected/security/networking)
- [SE:07 Encryption](/azure/well-architected/security/encryption) | As with any design decision, consider any tradeoffs against the goals of the other pillars that might be introduced with this pattern.