# SkillPatch skill: cloud-solution-architect Transforms an agent into a Cloud Solution Architect following Azure Architecture Center best practices. Covers 10 design principles, 6 architecture styles with selection guidance, 44 cloud design patterns mapped to Well-Architected Framework pillars, and technology choice frameworks for compute, storage, data, and messaging. Includes performance antipatterns and an architecture review workflow for systematic design validation. You (the agent) were given this URL and asked to use this skill. This is a **public** skill — no SkillPatch account, API key, or prior setup is required. Two ways to use it: **1. Use it right now** — the skill's complete file tree (SKILL.md + all reference files) is inlined below; read `SKILL.md` first, then follow it, consulting the other files as it directs. **2. Install the exact package onto disk** (recommended if you can run a shell — this reproduces the skill byte-for-byte, including any binary assets that can't be inlined): ```bash mkdir -p .claude/skills/cloud-solution-architect curl -sSL https://skillpatch.dev/install_skill/cloud-solution-architect | tar -xz -C .claude/skills/ ``` (`.claude/skills/` is Claude Code's convention; use whatever directory your agent loads skills from.) --- ## Skill files (8) - `SKILL.md` - `references/architecture-styles.md` - `references/best-practices.md` - `references/design-patterns.md` - `references/design-principles.md` - `references/mission-critical.md` - `references/performance-antipatterns.md` - `references/technology-choices.md` ### `SKILL.md` ````markdown --- name: cloud-solution-architect description: >- Transform the agent into a Cloud Solution Architect following Azure Architecture Center best practices. Use when designing cloud architectures, reviewing system designs, selecting architecture styles, applying cloud design patterns, making technology choices, or conducting Well-Architected Framework reviews. --- # Cloud Solution Architect ## Overview Design well-architected, production-grade cloud systems following Azure Architecture Center best practices. This skill provides: - **10 design principles** for Azure applications - **6 architecture styles** with selection guidance - **44 cloud design patterns** mapped to WAF pillars - **Technology choice frameworks** for compute, storage, data, messaging - **Performance antipatterns** to avoid - **Architecture review workflow** for systematic design validation --- ## Ten Design Principles for Azure Applications | # | Principle | Key Tactics | |---|-----------|-------------| | 1 | **Design for self-healing** | Retry with backoff, circuit breaker, bulkhead isolation, health endpoint monitoring, graceful degradation | | 2 | **Make all things redundant** | Eliminate single points of failure, use availability zones, deploy multi-region, replicate data | | 3 | **Minimize coordination** | Decouple services, use async messaging, embrace eventual consistency, use domain events | | 4 | **Design to scale out** | Horizontal scaling, autoscaling rules, stateless services, avoid session stickiness, partition workloads | | 5 | **Partition around limits** | Data partitioning (shard/hash/range), respect compute & network limits, use CDNs for static content | | 6 | **Design for operations** | Structured logging, distributed tracing, metrics & dashboards, runbook automation, infrastructure as code | | 7 | **Use managed services** | Prefer PaaS over IaaS, reduce operational burden, leverage built-in HA/DR/scaling | | 8 | **Use an identity service** | Microsoft Entra ID, managed identity, RBAC, avoid storing credentials, zero-trust principles | | 9 | **Design for evolution** | Loose coupling, versioned APIs, backward compatibility, async messaging for integration, feature flags | | 10 | **Build for business needs** | Define SLAs/SLOs, establish RTO/RPO targets, domain-driven design, cost modeling, composite SLAs | --- ## Architecture Styles | Style | Description | When to Use | Key Services | |-------|-------------|-------------|--------------| | **N-tier** | Horizontal layers (presentation, business, data) | Traditional enterprise apps, lift-and-shift | App Service, SQL Database, VNets | | **Web-Queue-Worker** | Web frontend → message queue → backend worker | Moderate-complexity apps with long-running tasks | App Service, Service Bus, Functions | | **Microservices** | Small autonomous services, bounded contexts, independent deploy | Complex domains, independent team scaling | AKS, Container Apps, API Management | | **Event-driven** | Pub/sub model, event producers/consumers | Real-time processing, IoT, reactive systems | Event Hubs, Event Grid, Functions | | **Big data** | Batch + stream processing pipeline | Analytics, ML pipelines, large-scale data | Synapse, Data Factory, Databricks | | **Big compute** | HPC, parallel processing | Simulations, modeling, rendering, genomics | Batch, CycleCloud, HPC VMs | ### Selection Criteria - **Domain complexity** → Microservices (high), N-tier (low-medium) - **Team autonomy** → Microservices (independent teams), N-tier (single team) - **Data volume** → Big data (TB+), others (GB) - **Latency requirements** → Event-driven (real-time), Web-Queue-Worker (tolerant) --- ## Cloud Design Patterns 44 patterns organized by primary concern. WAF pillar mapping: **R**=Reliability, **S**=Security, **CO**=Cost Optimization, **OE**=Operational Excellence, **PE**=Performance Efficiency. ### Messaging & Communication | Pattern | Summary | Pillars | |---------|---------|---------| | **Asynchronous Request-Reply** | Decouple request/response with polling or callbacks | R, PE | | **Claim Check** | Split large messages; store payload separately, pass reference | R, PE | | **Choreography** | Services coordinate via events without central orchestrator | R, OE | | **Competing Consumers** | Multiple consumers process messages from shared queue concurrently | R, PE | | **Messaging Bridge** | Connect incompatible messaging systems | R, OE | | **Pipes and Filters** | Decompose complex processing into reusable filter stages | R, OE | | **Priority Queue** | Prioritize requests so higher-priority work is processed first | R, PE | | **Publisher/Subscriber** | Decouple senders from receivers via topics/subscriptions | R, PE | | **Queue-Based Load Leveling** | Buffer requests with a queue to smooth intermittent loads | R, PE | | **Sequential Convoy** | Process related messages in order while allowing parallel groups | R, PE | ### Reliability & Resilience | Pattern | Summary | Pillars | |---------|---------|---------| | **Bulkhead** | Isolate resources per workload to prevent cascading failure | R | | **Circuit Breaker** | Stop calling a failing service; fail fast to protect resources | R | | **Compensating Transaction** | Undo previously committed steps when a later step fails | R | | **Health Endpoint Monitoring** | Expose health checks for load balancers and orchestrators | R, OE | | **Leader Election** | Coordinate distributed instances by electing a leader | R | | **Retry** | Handle transient faults by retrying with exponential backoff | R | | **Saga** | Manage data consistency across microservices with compensating transactions | R | | **Scheduler Agent Supervisor** | Coordinate distributed actions with retry and failure handling | R | ### Data Management | Pattern | Summary | Pillars | |---------|---------|---------| | **Cache-Aside** | Load data on demand into cache from data store | PE | | **CQRS** | Separate read and write models for independent scaling | PE, R | | **Event Sourcing** | Store state as append-only sequence of domain events | R, OE | | **Index Table** | Create indexes over frequently queried fields in data stores | PE | | **Materialized View** | Pre-compute views over data for efficient queries | PE | | **Sharding** | Distribute data across partitions for scale and performance | PE, R | | **Static Content Hosting** | Serve static content from cloud storage/CDN directly | PE, CO | | **Valet Key** | Grant clients limited direct access to storage resources | S, PE | ### Design & Structure | Pattern | Summary | Pillars | |---------|---------|---------| | **Ambassador** | Offload cross-cutting concerns to a helper sidecar proxy | OE | | **Anti-Corruption Layer** | Translate between new and legacy system models | OE, R | | **Backends for Frontends** | Create separate backends per frontend type (mobile, web, etc.) | OE, PE | | **Compute Resource Consolidation** | Combine multiple workloads into fewer compute instances | CO | | **External Configuration Store** | Externalize configuration from deployment packages | OE | | **Sidecar** | Deploy helper components alongside the main service | OE | | **Strangler Fig** | Incrementally migrate legacy systems by replacing pieces | OE, R | ### Security & Access | Pattern | Summary | Pillars | |---------|---------|---------| | **Federated Identity** | Delegate authentication to an external identity provider | S | | **Gatekeeper** | Protect services using a dedicated broker that validates requests | S | | **Quarantine** | Isolate and validate external assets before allowing use | S | | **Rate Limiting** | Control consumption rate of resources by consumers | R, S | | **Throttling** | Control resource consumption to sustain SLAs under load | R, PE | ### Deployment & Scaling | Pattern | Summary | Pillars | |---------|---------|---------| | **Deployment Stamps** | Deploy multiple independent copies of application components | R, PE | | **Edge Workload Configuration** | Configure workloads differently across diverse edge devices | OE | | **Gateway Aggregation** | Aggregate multiple backend calls into a single client request | PE | | **Gateway Offloading** | Offload shared functionality (SSL, auth) to a gateway | OE, S | | **Gateway Routing** | Route requests to multiple backends using a single endpoint | OE | | **Geode** | Deploy backends to multiple regions for active-active serving | R, PE | See [Design Patterns Reference](./references/design-patterns.md) for detailed implementation guidance. --- ## Technology Choices ### Decision Framework For each technology area, evaluate: **requirements → constraints → tradeoffs → select**. | Area | Key Options | Selection Criteria | |------|-------------|-------------------| | **Compute** | App Service, Functions, Container Apps, AKS, VMs, Batch | Hosting model, scaling, cost, team skills | | **Storage** | Blob Storage, Data Lake, Files, Disks, Managed Lustre | Access patterns, throughput, cost tier | | **Data stores** | SQL Database, Cosmos DB, PostgreSQL, Redis, Table Storage | Consistency model, query patterns, scale | | **Messaging** | Service Bus, Event Hubs, Event Grid, Queue Storage | Ordering, throughput, pub/sub vs queue | | **Networking** | Front Door, Application Gateway, Load Balancer, Traffic Manager | Global vs regional, L4 vs L7, WAF | | **AI services** | Azure OpenAI, AI Search, AI Foundry, Document Intelligence | Model needs, data grounding, orchestration | | **Containers** | Container Apps, AKS, Container Instances | Operational control vs simplicity | See [Technology Choices Reference](./references/technology-choices.md) for detailed decision trees. --- ## Best Practices | Practice | Key Guidance | |----------|-------------| | **API design** | RESTful conventions, resource-oriented URIs, HATEOAS, versioning via URL path or header | | **API implementation** | Async operations, pagination, idempotent PUT/DELETE, content negotiation, ETag caching | | **Autoscaling** | Scale on metrics (CPU, queue depth, custom), cool-down periods, predictive scaling, scale-in protection | | **Background jobs** | Use queues or scheduled triggers, idempotent processing, poison message handling, graceful shutdown | | **Caching** | Cache-aside pattern, TTL policies, cache invalidation strategies, distributed cache for multi-instance | | **CDN** | Static asset offloading, cache-busting with versioned URLs, geo-distribution, HTTPS enforcement | | **Data partitioning** | Horizontal (sharding), vertical, functional partitioning; partition key selection for even distribution | | **Partitioning strategies** | Hash-based, range-based, directory-based; rebalancing approach, cross-partition query avoidance | | **Host name preservation** | Preserve original host header through proxies/gateways for cookies, redirects, auth flows | | **Message encoding** | Schema evolution (Avro/Protobuf), backward/forward compatibility, schema registry | | **Monitoring & diagnostics** | Structured logging, distributed tracing (W3C Trace Context), metrics, alerts, dashboards | | **Transient fault handling** | Retry with exponential backoff + jitter, circuit breaker, idempotency keys, timeout budgets | See [Best Practices Reference](./references/best-practices.md) for implementation details. --- ## Performance Antipatterns Avoid these common patterns that degrade performance under load: | Antipattern | Problem | Fix | |-------------|---------|-----| | **Busy Database** | Offloading too much processing to the database | Move logic to application tier, use caching | | **Busy Front End** | Resource-intensive work on frontend request threads | Offload to background workers/queues | | **Chatty I/O** | Many small I/O requests instead of fewer large ones | Batch requests, use bulk APIs, buffer writes | | **Extraneous Fetching** | Retrieving more data than needed | Project only required fields, paginate, filter server-side | | **Improper Instantiation** | Recreating expensive objects per request | Use singletons, connection pooling, HttpClientFactory | | **Monolithic Persistence** | Single data store for all data types | Polyglot persistence — right store for each workload | | **No Caching** | Repeatedly fetching unchanged data | Cache-aside pattern, CDN, output caching, Redis | | **Noisy Neighbor** | One tenant consuming all shared resources | Bulkhead isolation, per-tenant quotas, throttling | | **Retry Storm** | Aggressive retries overwhelming a recovering service | Exponential backoff + jitter, circuit breaker, retry budgets | | **Synchronous I/O** | Blocking threads on I/O operations | Async/await, non-blocking I/O, reactive streams | --- ## Mission-Critical Design For workloads targeting **99.99%+ SLO**, address these design areas: | Design Area | Key Considerations | |-------------|-------------------| | **Application platform** | Multi-region active-active, availability zones, Container Apps or AKS with zone redundancy | | **Application design** | Stateless services, idempotent operations, graceful degradation, bulkhead isolation | | **Networking** | Azure Front Door (global LB), DDoS Protection, private endpoints, redundant connectivity | | **Data platform** | Multi-region Cosmos DB, zone-redundant SQL, async replication, conflict resolution | | **Deployment & testing** | Blue-green deployments, canary releases, chaos engineering, automated rollback | | **Health modeling** | Composite health scores, dependency health tracking, automated remediation, SLI dashboards | | **Security** | Zero-trust, managed identity everywhere, key rotation, WAF policies, threat modeling | | **Operational procedures** | Automated runbooks, incident response playbooks, game days, postmortems | See [Mission-Critical Reference](./references/mission-critical.md) for detailed guidance. --- ## Well-Architected Framework (WAF) Pillars Every architecture decision should be evaluated against all five pillars: | Pillar | Focus | Key Questions | |--------|-------|---------------| | **Reliability** | Resiliency, availability, disaster recovery | What is the RTO/RPO? How does it handle failures? Is there redundancy? | | **Security** | Threat protection, identity, data protection | Is identity managed? Is data encrypted? Are there network controls? | | **Cost Optimization** | Cost management, efficiency, right-sizing | Is compute right-sized? Are there reserved instances? Is there waste? | | **Operational Excellence** | Monitoring, deployment, automation | Is deployment automated? Is there observability? Are there runbooks? | | **Performance Efficiency** | Scaling, load testing, performance targets | Can it scale horizontally? Are there performance baselines? Is caching used? | ### WAF Tradeoff Matrix | Optimizing for... | May impact... | |-------------------|---------------| | Reliability (redundancy) | Cost (more resources) | | Security (isolation) | Performance (added latency) | | Cost (consolidation) | Reliability (shared failure domains) | | Performance (caching) | Cost (cache infrastructure), Reliability (stale data) | --- ## Architecture Review Workflow When reviewing or designing a system, follow this structured approach: ### Step 1: Identify Requirements ``` Functional: What must the system do? Non-functional: - Availability target (e.g., 99.9%, 99.99%) - Latency requirements (p50, p95, p99) - Throughput (requests/sec, messages/sec) - Data residency and compliance - Recovery targets (RTO, RPO) - Cost constraints ``` ### Step 2: Select Architecture Style Match requirements to architecture style using the selection criteria table above. ### Step 3: Choose Technology Stack Use the technology choices decision framework. Prefer managed services (PaaS) over IaaS. ### Step 4: Apply Design Patterns Select relevant patterns from the 44 cloud design patterns based on identified concerns. ### Step 5: Address Cross-Cutting Concerns - **Identity & access** — Microsoft Entra ID, managed identity, RBAC - **Monitoring** — Application Insights, Azure Monitor, Log Analytics - **Security** — Network segmentation, encryption at rest/in transit, Key Vault - **CI/CD** — GitHub Actions, Azure DevOps Pipelines, infrastructure as code ### Step 6: Validate Against WAF Pillars Review each pillar systematically. Document tradeoffs explicitly. ### Step 7: Document Decisions Use Architecture Decision Records (ADRs): ```markdown # ADR-NNN: [Decision Title] ## Status: [Proposed | Accepted | Deprecated] ## Context [What is the issue we're addressing?] ## Decision [What did we decide and why?] ## Consequences [What are the positive and negative impacts?] ``` --- ## References - [Design Patterns Reference](./references/design-patterns.md) — Detailed pattern implementations - [Technology Choices Reference](./references/technology-choices.md) — Decision trees for Azure services - [Best Practices Reference](./references/best-practices.md) — Implementation guidance - [Mission-Critical Reference](./references/mission-critical.md) — High-availability design --- ## Source Content derived from the [Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/) — Microsoft's official guidance for cloud solution architecture on Azure. Covers design principles, architecture styles, cloud design patterns, technology choices, best practices, performance antipatterns, mission-critical design, and the Well-Architected Framework. ```` ### `references/architecture-styles.md` ````markdown # Azure Architecture Styles Reference ## Comparison Table | Style | Dependency Management | Domain Type | |---|---|---| | N-tier | Horizontal tiers divided by subnet | Traditional business, low update frequency | | Web-Queue-Worker | Front/back-end decoupled by async messaging | Simple domain, resource-intensive tasks | | Microservices | Vertically decomposed services via APIs | Complex domain, frequent updates | | Event-driven | Producer/consumer, independent views | IoT, real-time systems | | Big data | Divide into small chunks, parallel processing | Batch/real-time data analysis, ML | | Big compute | Data allocation to thousands of cores | Compute-intensive (simulation) | --- ## 1. N-tier Traditional architecture that divides an application into logical layers and physical tiers. Each layer has a specific responsibility and communicates only with the layer directly below it. ### Logical Diagram ``` ┌──────────────────────────────────┐ │ Presentation Tier │ ← Web / UI │ (Subnet A) │ ├──────────────────────────────────┤ │ Business Logic Tier │ ← Rules / Workflows │ (Subnet B) │ ├──────────────────────────────────┤ │ Data Access Tier │ ← Database / Storage │ (Subnet C) │ └──────────────────────────────────┘ ``` ### Benefits - Familiar pattern for most development teams - Natural mapping for migrating existing layered applications to Azure - Clear separation of concerns between tiers ### Challenges - Horizontal layering makes cross-cutting changes difficult — a single feature may touch every tier - Limits agility and release velocity as tiers are tightly coupled vertically ### Best Practices - Use VNet subnets to isolate tiers and control traffic flow with NSGs - Keep each tier stateless where possible to enable horizontal scaling - Use managed services (App Service, Azure SQL) to reduce operational overhead ### Dependency Management Horizontal tiers divided by subnet. Each tier depends only on the tier directly below it, enforced through network segmentation. ### Recommended Azure Services - Azure App Service - Azure SQL Database - Azure Virtual Machines - Azure Virtual Network (subnets) --- ## 2. Web-Queue-Worker A web front end handles HTTP requests while a worker process performs resource-intensive or long-running tasks. The two components communicate through an asynchronous message queue. ### Logical Diagram ``` ┌───────────┐ HTTP ─────────►│ Web │ Requests │ Front End │ └─────┬─────┘ │ ▼ ┌──────────────┐ │ Message │ │ Queue │ └──────┬───────┘ │ ▼ ┌───────────┐ │ Worker │ │ Process │ └─────┬─────┘ │ ▼ ┌───────────┐ │ Database │ └───────────┘ ``` ### Benefits - Easy to understand and deploy, especially with managed compute services - Clean separation between interactive and background workloads - Each component can scale independently ### Challenges - Without careful design, the front end and worker can become monolithic components that are hard to maintain and update - Hidden dependencies may emerge if front end and worker share data schemas or storage ### Best Practices - Keep the web front end thin — delegate heavy processing to the worker - Use durable message queues to ensure work is not lost on failure - Design idempotent worker operations to handle message retries safely ### Dependency Management Front-end and back-end jobs are decoupled by asynchronous messaging. The web tier never calls the worker directly; all communication flows through the queue. ### Recommended Azure Services - Azure App Service - Azure Functions - Azure Queue Storage - Azure Service Bus --- ## 3. Microservices A collection of small, autonomous services where each service implements a single business capability. Each service owns its bounded context and data, and communicates with other services via well-defined APIs. ### Logical Diagram ``` ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Service │ │ Service │ │ Service │ │ A │ │ B │ │ C │ │ ┌──────┐ │ │ ┌──────┐ │ │ ┌──────┐ │ │ │ Data │ │ │ │ Data │ │ │ │ Data │ │ │ └──────┘ │ │ └──────┘ │ │ └──────┘ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └──────┬───────┘──────────────┘ ▼ ┌──────────────┐ │ API Gateway │ └──────┬───────┘ │ Clients ``` ### Benefits - Autonomous teams can develop, deploy, and scale services independently - Enables frequent updates and higher release velocity - Technology diversity — each service can use the stack best suited to its task ### Challenges - Service discovery and inter-service communication add complexity - Data consistency across services requires patterns like Saga or eventual consistency - Distributed system management (monitoring, debugging, tracing) is inherently harder ### Best Practices - Define clear bounded contexts — avoid sharing databases between services - Use an API gateway for cross-cutting concerns (auth, rate limiting, routing) - Implement health checks, circuit breakers, and distributed tracing from day one ### Dependency Management Vertically decomposed services calling each other via APIs. Each service is independently deployable with its own data store, minimizing coupling. ### Recommended Azure Services - Azure Kubernetes Service (AKS) - Azure Container Apps - Azure API Management - Azure Service Bus - Azure Cosmos DB --- ## 4. Event-driven A publish-subscribe architecture where event producers emit events and event consumers react to them. Producers and consumers are fully decoupled, communicating only through event channels or brokers. ### Logical Diagram ``` ┌──────────┐ ┌──────────────────┐ ┌──────────┐ │ Producer │────►│ │────►│ Consumer │ │ A │ │ Event Broker │ │ A │ └──────────┘ │ / Channel │ └──────────┘ │ │ ┌──────────┐ │ ┌────────────┐ │ ┌──────────┐ │ Producer │────►│ │ Pub/Sub │ │────►│ Consumer │ │ B │ │ │ or Stream │ │ │ B │ └──────────┘ │ └────────────┘ │ └──────────┘ └──────────────────┘ ``` **Two models:** Pub/Sub (events delivered to subscribers) and Event Streaming (events written to an ordered log for consumers to read). **Consumer variations:** Simple event processing, basic correlation, complex event processing, event stream processing. ### Benefits - Producers and consumers are fully decoupled — they can evolve independently - Highly scalable — add consumers without affecting producers - Responsive and well-suited to real-time processing pipelines ### Challenges - Guaranteed delivery requires careful broker configuration and dead-letter handling - Event ordering can be difficult to maintain across partitions - Eventual consistency — consumers may see stale data temporarily - Error handling and poison message management add operational complexity ### Best Practices - Design events as immutable facts with clear schemas - Use dead-letter queues for events that fail processing - Implement idempotent consumers to handle duplicate delivery safely ### Dependency Management Producer/consumer model with independent views per subsystem. Producers have no knowledge of consumers; each subsystem maintains its own projection of the event stream. ### Recommended Azure Services - Azure Event Grid - Azure Event Hubs - Azure Functions - Azure Service Bus - Azure Stream Analytics --- ## 5. Big Data Architecture designed to handle ingestion, processing, and analysis of data that is too large or complex for traditional database systems. ### Logical Diagram ``` ┌─────────────┐ ┌──────────────────────────────────┐ │ Data Sources│───►│ Data Storage │ │ (logs, IoT, │ │ (Data Lake) │ │ files) │ └──┬──────────────┬─────────────────┘ └─────────────┘ │ │ ▼ ▼ ┌──────────────┐ ┌──────────────┐ │ Batch │ │ Real-time │ │ Processing │ │ Processing │ └──────┬───────┘ └──────┬───────┘ │ │ ▼ ▼ ┌───────────────────────────────┐ │ Analytical Data Store │ └──────────────┬────────────────┘ │ ┌──────────────▼────────────────┐ │ Analysis & Reporting │ │ (Dashboards, ML Models) │ └───────────────────────────────┘ Orchestration manages the full pipeline ``` **Components:** Data sources → Data storage (data lake) → Batch processing → Real-time processing → Analytical data store → Analysis and reporting → Orchestration. ### Benefits - Process massive datasets that exceed traditional database capacity - Support both batch and real-time analytics in a single architecture - Enable predictive analytics and machine learning at scale ### Challenges - Complexity of coordinating batch and real-time processing paths - Data quality and governance across a data lake require disciplined schema management - Cost management — large-scale storage and compute can grow unpredictably ### Best Practices - Use parallelism for both batch and real-time processing - Partition data to enable parallel reads and writes - Apply schema-on-read semantics to keep ingestion flexible - Process data in batches on arrival rather than waiting for scheduled windows - Balance usage costs against time-to-insight requirements ### Dependency Management Divide huge datasets into small chunks for parallel processing. Each chunk can be processed independently, with an orchestration layer coordinating the overall pipeline. ### Recommended Azure Services - Microsoft Fabric - Azure Data Lake Storage - Azure Event Hubs - Azure SQL Database - Azure Cosmos DB - Power BI --- ## 6. Big Compute Architecture for large-scale workloads that require hundreds or thousands of cores running in parallel. Tasks can be independent (embarrassingly parallel) or tightly coupled requiring inter-node communication. ### Logical Diagram ``` ┌─────────────────────────────────────────────┐ │ Job Scheduler │ │ (submit, monitor, manage) │ └─────────────────┬───────────────────────────┘ │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ ┌────────┐ ┌────────┐ ┌────────────────┐ │ Core │ │ Core │ │ Core │ │ Pool 1 │ │ Pool 2 │ │ Pool N │ │(100s) │ │(100s) │ │(1000s of cores)│ └───┬────┘ └───┬────┘ └───┬────────────┘ │ │ │ └─────────┬─┘────────────┘ ▼ ┌──────────────┐ │ Results │ │ Storage │ └──────────────┘ ``` **Use cases:** Simulations, financial risk modeling, oil exploration, drug design, image rendering. ### Benefits - High performance through massive parallel processing - Access to specialized hardware (GPU, FPGA, InfiniBand) for compute-intensive workloads - Scales to thousands of cores for embarrassingly parallel problems ### Challenges - Managing VM infrastructure at scale (provisioning, patching, decommissioning) - Provisioning thousands of cores in a timely manner to meet job deadlines - Cost control — idle compute resources are expensive ### Best Practices - Use low-priority or spot VMs to reduce cost for fault-tolerant workloads - Auto-scale compute pools based on job queue depth - Partition work into independent tasks when possible to maximize parallelism ### Dependency Management Data allocation to thousands of cores. The job scheduler distributes work units across the compute pool, with each core processing its assigned data partition independently. ### Recommended Azure Services - Azure Batch - Microsoft HPC Pack - H-series Virtual Machines (HPC-optimized) --- > Source: [Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/) ```` ### `references/best-practices.md` ```markdown # Cloud Application Best Practices Twelve best practices from the Azure Architecture Center for designing, building, and operating cloud applications. --- ## 1. API Design Design RESTful web APIs that promote platform independence and loose coupling between clients and services. ### Key Recommendations - Organize APIs around resources using nouns, not verbs, in URIs - Use standard HTTP methods (GET, POST, PUT, PATCH, DELETE) with correct semantics - Use plural nouns for collection endpoints (e.g., `/orders`, `/customers`) - Support HATEOAS to enable client navigation of the API without prior knowledge - Design coarse-grained operations to avoid chatty request patterns - Do not expose internal database structure through the API surface - Version APIs to manage breaking changes without disrupting existing clients - Return appropriate HTTP status codes and consistent error response bodies ### WAF Pillar Alignment Performance Efficiency · Operational Excellence ### Common Mistakes - Using verbs in URIs (e.g., `/getOrders`) instead of resource-based paths - Exposing database schema directly through API contracts - Creating chatty APIs that require multiple round-trips for a single logical operation --- ## 2. API Implementation Implement web APIs to be efficient, responsive, scalable, and available for consuming clients. ### Key Recommendations - Make actions idempotent so retries are safe (especially PUT and DELETE) - Support content negotiation via `Accept` and `Content-Type` headers - Follow the HTTP specification for status codes, methods, and headers - Handle exceptions gracefully and return meaningful error responses - Support resource discovery through links and metadata - Limit and paginate large result sets to minimize network traffic - Handle large requests asynchronously using `202 Accepted` with status polling - Compress responses where appropriate to reduce payload size ### WAF Pillar Alignment Operational Excellence ### Common Mistakes - Not handling large requests asynchronously, causing timeouts - Not minimizing network traffic through pagination, filtering, or compression --- ## 3. Autoscaling Dynamically allocate and deallocate resources to match performance requirements while optimizing cost. ### Key Recommendations - Use Azure Monitor autoscale and built-in platform autoscaling features - Scale based on metrics that directly correlate with load (CPU, queue length, request rate) - Combine schedule-based and metric-based scaling for predictable traffic patterns - Set appropriate minimum, maximum, and default instance counts - Configure scale-in rules as carefully as scale-out rules - Use cooldown periods to prevent oscillation (flapping) - Plan for the delay between triggering a scale event and resources becoming available ### WAF Pillar Alignment Performance Efficiency · Cost Optimization ### Common Mistakes - Not setting appropriate minimum and maximum limits for scaling - Not considering scale-in behavior, leading to premature resource removal - Using metrics that do not accurately reflect application load --- ## 4. Background Jobs Implement batch processing, long-running tasks, and workflows as background jobs decoupled from the user interface. ### Key Recommendations - Use Azure platform services such as Functions, WebJobs, and Batch for hosting - Trigger background jobs with events, schedules, or message queues - Return results to calling tasks through queues, events, or shared storage - Design jobs to be independently deployable, scalable, and versioned - Handle partial failures and support safe restarts with checkpointing - Monitor job health with logging, metrics, and alerting - Implement graceful shutdown to allow in-progress work to complete ### WAF Pillar Alignment Operational Excellence ### Common Mistakes - Not handling failures or partial completion within long-running jobs - Not monitoring background job health, missing silent failures --- ## 5. Caching Copy frequently read, rarely modified data to fast storage close to the application to improve performance. ### Key Recommendations - Cache data that is read often but changes infrequently - Use Azure Cache for Redis for distributed, high-throughput caching - Set appropriate expiration policies (TTL) to balance freshness and hit rates - Handle cache misses gracefully with a cache-aside pattern - Address concurrency issues when multiple processes update the same cached data - Implement cache invalidation strategies aligned with data change patterns - Pre-populate caches for known hot data during application startup ### WAF Pillar Alignment Performance Efficiency ### Common Mistakes - Caching highly volatile data that expires before it can be served - Not handling cache invalidation, serving stale data to users - Cache stampede — many concurrent requests regenerating the same expired entry --- ## 6. CDN (Content Delivery Network) Use CDNs to deliver static and dynamic web content efficiently to users from edge locations worldwide. ### Key Recommendations - Offload static assets (images, scripts, stylesheets) to the CDN to reduce origin load - Configure appropriate cache-control headers for each content type - Version static content via file names or query strings for reliable cache busting - Use HTTPS and enforce TLS for secure delivery - Plan for CDN fallback so the application degrades gracefully if the CDN is unavailable - Handle deployment and versioning so users receive updated content promptly ### WAF Pillar Alignment Performance Efficiency ### Common Mistakes - Not versioning content, causing users to receive stale cached assets after deployments - Setting improper cache headers, resulting in under-caching or over-caching --- ## 7. Data Partitioning Divide data stores into partitions to improve scalability, availability, and performance while reducing contention and storage costs. ### Key Recommendations - Choose partition keys that distribute data and load evenly across partitions - Use horizontal (sharding), vertical, or functional partitioning based on access patterns - Minimize cross-partition queries to avoid performance degradation - Design partitions to match the most common query patterns - Plan for rebalancing as data volume and access patterns evolve - Consider partition limits and throughput caps of the target data store - Reduce contention and storage costs by separating hot and cold data ### WAF Pillar Alignment Performance Efficiency · Cost Optimization ### Common Mistakes - Creating hotspots by selecting a partition key with skewed distribution - Not considering the cost and latency of cross-partition queries --- ## 8. Data Partitioning Strategies (by Service) Apply service-specific partitioning strategies across Azure SQL Database, Azure Table Storage, Azure Blob Storage, and other data services. ### Key Recommendations - Shard Azure SQL Database to distribute data for horizontal scaling - Design Azure Table Storage partition keys around query access patterns - Organize Azure Blob Storage using virtual directories and naming conventions - Align partition boundaries with the most frequent query predicates - Reduce latency by co-locating related data within the same partition - Monitor partition metrics and rebalance when skew is detected ### WAF Pillar Alignment Performance Efficiency · Cost Optimization ### Common Mistakes - Not aligning the partition strategy with actual query patterns, causing full scans - Ignoring service-specific partition limits and throttling thresholds --- ## 9. Host Name Preservation Preserve the original HTTP host name between reverse proxies and backend web applications to avoid issues with cookies, redirects, and CORS. ### Key Recommendations - Forward the original `Host` header from the reverse proxy to the backend - Configure Azure Front Door, Application Gateway, and API Management for host preservation - Ensure cookies are set with the correct domain matching the original host name - Verify redirect URLs reference the external host name, not the internal backend address - Test CORS configurations end-to-end with the preserved host name - Document host name flow across all network hops in the architecture ### WAF Pillar Alignment Reliability ### Common Mistakes - Not preserving host headers, causing redirect loops or incorrect absolute URLs - Breaking session cookies because the cookie domain does not match the forwarded host --- ## 10. Message Encoding Choose the right payload structure, encoding format, and serialization library for asynchronous messages exchanged between distributed components. ### Key Recommendations - Evaluate JSON, Avro, Protobuf, and MessagePack based on performance and interoperability needs - Use schema registries to enforce and version message contracts - Validate incoming messages against their schemas before processing - Prefer compact binary formats (Protobuf, Avro) for high-throughput, latency-sensitive paths - Use JSON for human-readable messages and broad ecosystem compatibility - Consider backward and forward compatibility when evolving message schemas ### WAF Pillar Alignment Security ### Common Mistakes - Using an inefficient encoding format for high-volume message streams - Not validating message schemas, allowing malformed data into the processing pipeline --- ## 11. Monitoring and Diagnostics Track system health, usage, and performance through a comprehensive monitoring pipeline that turns raw data into alerts, reports, and automated triggers. ### Key Recommendations - Instrument applications with structured logging, metrics, and distributed tracing - Use Azure Monitor, Application Insights, and Log Analytics as the monitoring backbone - Define actionable alerts with clear thresholds, severity levels, and response procedures - Detect and correct issues before they affect users by monitoring leading indicators - Correlate telemetry across services using distributed trace context (e.g., correlation IDs) - Establish performance baselines and track deviations over time - Build dashboards for operational visibility across all tiers of the architecture - Review and tune alert rules regularly to reduce noise ### WAF Pillar Alignment Operational Excellence ### Common Mistakes - Insufficient logging, making incident root-cause analysis slow or impossible - Not using distributed tracing in microservice or multi-tier architectures - Alert fatigue from poorly tuned thresholds that generate excessive false positives --- ## 12. Transient Fault Handling Detect and handle transient faults caused by momentary loss of network connectivity, temporary service unavailability, or resource throttling. ### Key Recommendations - Implement retry logic with exponential backoff and jitter for transient failures - Use a circuit breaker pattern to stop retrying when failures are persistent - Distinguish transient faults (e.g., HTTP 429, 503) from permanent errors (e.g., 400, 404) - Leverage built-in retry policies in Azure SDKs before adding custom retry logic - Avoid duplicating retry layers across middleware and application code - Log every retry attempt for post-incident analysis - Set a maximum retry count and total timeout to bound retry duration ### WAF Pillar Alignment Reliability ### Common Mistakes - Retrying non-transient faults (e.g., authentication failures, bad requests) - Not using exponential backoff, overwhelming a recovering service with constant retries - Retry storms caused by multiple layers retrying simultaneously without coordination --- > Source: [Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/) ``` ### `references/design-patterns.md` ```markdown # Cloud Design Patterns A comprehensive reference of all 44 cloud design patterns from the Azure Architecture Center, organized by concern area and detailed with problem context, usage scenarios, WAF pillar alignment, and related patterns. --- ## Patterns by Concern ### Availability / Reliability Circuit Breaker · Compensating Transaction · Health Endpoint Monitoring · Leader Election · Queue-Based Load Leveling · Retry · Saga · Scheduler Agent Supervisor · Sequential Convoy · Bulkhead · Rate Limiting ### Data Management Cache-Aside · CQRS · Event Sourcing · Index Table · Materialized View · Sharding · Valet Key · Claim Check ### Design / Implementation Ambassador · Anti-Corruption Layer · Backends for Frontends · Compute Resource Consolidation · Deployment Stamps · External Configuration Store · Gateway Aggregation · Gateway Offloading · Gateway Routing · Sidecar · Strangler Fig · Federated Identity ### Messaging Asynchronous Request-Reply · Choreography · Claim Check · Competing Consumers · Messaging Bridge · Pipes and Filters · Priority Queue · Publisher/Subscriber · Queue-Based Load Leveling · Sequential Convoy ### Performance / Scalability Cache-Aside · Geode · Throttling · Deployment Stamps · CQRS ### Security Gatekeeper · Quarantine · Valet Key · Federated Identity · Throttling --- ## Pattern Reference ### 1. Ambassador **Create helper services that send network requests on behalf of a consumer service or application.** **Problem:** Applications need common connectivity features such as monitoring, logging, routing, security (TLS), and resiliency patterns. Legacy or difficult-to-modify apps may not support these features natively. Network calls require substantial configuration for concerns such as circuit breaking, routing, metering, and telemetry. **When to use:** - You need a common set of client connectivity features across multiple languages or frameworks - The connectivity concern is owned by infrastructure teams or another specialized team - You need to reduce the age or complexity of legacy app networking without modifying source code - You want to standardize observability and resiliency across polyglot services **WAF Pillars:** Reliability, Security **Related patterns:** Sidecar, Gateway Routing, Gateway Offloading --- ### 2. Anti-Corruption Layer **Implement a façade or adapter layer between a modern application and a legacy system.** **Problem:** During migration, the new system must often integrate with the legacy system's data model or API, which may use outdated schemas, protocols, or design conventions. Allowing the modern application to depend on legacy contracts contaminates its design and limits future evolution. **When to use:** - A migration is planned over multiple phases and the old and new systems must coexist - The new system's domain model differs significantly from the legacy system - You want to prevent legacy coupling from leaking into modern components - Two bounded contexts (DDD) need to communicate but have incompatible models **WAF Pillars:** Operational Excellence **Related patterns:** Strangler Fig, Gateway Routing --- ### 3. Asynchronous Request-Reply **Decouple backend processing from a frontend host, where backend processing needs to be asynchronous but the frontend still needs a clear response.** **Problem:** In many architectures, the client expects an immediate acknowledgement while the actual work happens in the background. The client needs a way to learn the result of the background operation without holding a long-lived connection or repeatedly guessing when processing completes. **When to use:** - Backend processing may take seconds to minutes and the client should not block - Client-side code such as a browser app cannot provide a callback endpoint - You want to expose an HTTP API where the server initiates long-running work and the client polls for results - You need an alternative to WebSocket or server-sent events for status updates **WAF Pillars:** Performance Efficiency **Related patterns:** Competing Consumers, Pipes and Filters, Queue-Based Load Leveling --- ### 4. Backends for Frontends **Create separate backend services to be consumed by specific frontend applications or interfaces.** **Problem:** A general-purpose backend API tends to accumulate conflicting requirements from different frontends (mobile, web, desktop, IoT). Over time the backend becomes bloated and changes for one frontend risk breaking another. Release cadences diverge and the single backend becomes a bottleneck. **When to use:** - A shared backend must be maintained with significant development overhead for multiple frontends - You want to optimize each backend for the constraints of a specific client (bandwidth, latency, payload shape) - Different frontend teams need independent release cycles for their backend logic - A single backend would require complex, client-specific branching logic **WAF Pillars:** Reliability, Security, Performance Efficiency **Related patterns:** Gateway Aggregation, Gateway Offloading, Gateway Routing --- ### 5. Bulkhead **Isolate elements of an application into pools so that if one fails, the others continue to function.** **Problem:** A cloud-based application may call multiple downstream services. If a single downstream becomes slow or unresponsive, the caller's thread pool or connection pool can be exhausted, causing cascading failure that takes down unrelated functionality. **When to use:** - You need to protect critical consumers from failures in non-critical downstream dependencies - A single noisy tenant or request type should not degrade service for others - You want to limit the blast radius of a downstream fault - The application calls multiple services with differing SLAs **WAF Pillars:** Reliability, Security, Performance Efficiency **Related patterns:** Circuit Breaker, Retry, Throttling, Queue-Based Load Leveling --- ### 6. Cache-Aside **Load data on demand into a cache from a data store.** **Problem:** Applications frequently read the same data from a data store. Repeated round trips increase latency and reduce throughput. Data stores may throttle or become expensive under high read loads. **When to use:** - The data store is read-heavy and the same data is requested frequently - The data store does not natively provide caching - Data can tolerate short periods of staleness - You want to reduce cost and latency of repeated reads **WAF Pillars:** Reliability, Performance Efficiency **Related patterns:** Materialized View, Event Sourcing, CQRS --- ### 7. Choreography **Have each component of the system participate in the decision-making process about the workflow of a business transaction, instead of relying on a central point of control.** **Problem:** A central orchestrator can become a single point of failure, a performance bottleneck, or a source of tight coupling. Changes to the workflow require changes to the orchestrator, which may be owned by a different team. **When to use:** - Services are independently deployable and owned by separate teams - The workflow changes frequently and a central orchestrator would become a maintenance burden - You want to avoid a single point of failure in workflow coordination - Services need loose coupling and can react to events **WAF Pillars:** Operational Excellence, Performance Efficiency **Related patterns:** Publisher/Subscriber, Saga, Competing Consumers --- ### 8. Circuit Breaker **Handle faults that might take a variable amount of time to fix when connecting to a remote service or resource.** **Problem:** Transient faults are handled by the Retry pattern, but when a downstream service is unavailable for an extended period, retries waste resources and block callers. Continuing to send requests to a failing service prevents it from recovering and wastes the caller's threads, connections, and compute. **When to use:** - A remote dependency experiences intermittent prolonged outages - You need to fail fast rather than make callers wait for a timeout - You want to give a failing downstream time to recover before sending more requests - You want to surface degraded functionality instead of hard failures **WAF Pillars:** Reliability, Performance Efficiency **Related patterns:** Retry, Bulkhead, Health Endpoint Monitoring, Ambassador --- ### 9. Claim Check **Split a large message into a claim check and payload to avoid overwhelming the messaging infrastructure.** **Problem:** Message brokers and queues often have size limits and charge per message. Sending large payloads (images, documents, datasets) through the messaging channel wastes bandwidth, increases cost, and may hit transport limits. **When to use:** - The message payload exceeds the messaging system's size limit - You want to reduce messaging costs by keeping message bodies small - Not all consumers need the full payload; some only need metadata - You need to protect sensitive payload data by separating access control from the messaging channel **WAF Pillars:** Reliability, Security, Cost Optimization, Performance Efficiency **Related patterns:** Competing Consumers, Pipes and Filters, Publisher/Subscriber --- ### 10. Compensating Transaction **Undo the work performed by a series of steps, which together define an eventually consistent operation.** **Problem:** In distributed systems, multi-step operations cannot rely on traditional ACID transactions. If a later step fails, the previous steps have already committed. The system needs a mechanism to reverse or compensate for the work done by the completed steps. **When to use:** - Multi-step operations span multiple services or data stores that do not share a transaction coordinator - You need to maintain consistency when a step in a distributed workflow fails - Rolling back is semantically meaningful (refund a charge, release a reservation) - The cost of inconsistency outweighs the complexity of compensation logic **WAF Pillars:** Reliability **Related patterns:** Saga, Retry, Scheduler Agent Supervisor --- ### 11. Competing Consumers **Enable multiple concurrent consumers to process messages received on the same messaging channel.** **Problem:** At peak load, a single consumer cannot keep up with the volume of incoming messages. Messages queue up, latency increases, and the system may breach its SLAs. **When to use:** - The workload varies significantly and you need to scale message processing dynamically - You require high availability—if one consumer fails, others continue processing - Multiple messages are independent and can be processed in parallel - You want to distribute work across multiple instances or nodes **WAF Pillars:** Reliability, Cost Optimization, Performance Efficiency **Related patterns:** Queue-Based Load Leveling, Priority Queue, Publisher/Subscriber, Pipes and Filters --- ### 12. Compute Resource Consolidation **Consolidate multiple tasks or operations into a single computational unit.** **Problem:** Deploying each small task or component as a separate service introduces operational overhead: more deployments, monitoring endpoints, and infrastructure cost. Many lightweight components are underutilized most of the time, wasting allocated compute. **When to use:** - Several lightweight processes have low CPU or memory usage individually - You want to reduce deployment and operational overhead - Processes share the same scaling profile and lifecycle - Communication between tasks benefits from being in-process rather than over the network **WAF Pillars:** Cost Optimization, Operational Excellence, Performance Efficiency **Related patterns:** Sidecar, Backends for Frontends --- ### 13. CQRS (Command and Query Responsibility Segregation) **Segregate operations that read data from operations that update data by using separate interfaces.** **Problem:** In traditional CRUD architectures, the same data model is used for reads and writes. This creates tension: read models want denormalized, query-optimized shapes while write models want normalized, consistency-optimized shapes. As the system grows, the shared model becomes a compromise that serves neither concern well. **When to use:** - Read and write workloads are asymmetric (far more reads than writes, or vice versa) - Read and write models have different schema requirements - You want to scale read and write sides independently - The domain benefits from an event-driven or task-based style rather than CRUD **WAF Pillars:** Performance Efficiency **Related patterns:** Event Sourcing, Materialized View, Cache-Aside --- ### 14. Deployment Stamps **Deploy multiple independent copies of application components, including data stores.** **Problem:** A single shared deployment for all tenants or regions creates coupling. A fault in one tenant's workload can affect all tenants. Regulatory requirements may mandate data residency. Scaling the entire deployment for a single tenant's spike is wasteful. **When to use:** - You need to isolate tenants for compliance, performance, or fault isolation - Your application must serve multiple geographic regions with data residency requirements - You need independent scaling per tenant group or region - You want blue/green or canary deployments at the stamp level **WAF Pillars:** Operational Excellence, Performance Efficiency **Related patterns:** Geode, Sharding, Throttling --- ### 15. Edge Workload Configuration **Centrally configure workloads that run at the edge, managing configuration drift and deployment consistency across heterogeneous edge devices.** **Problem:** Edge devices are numerous, heterogeneous, and often intermittently connected. Deploying and configuring workloads individually is error-prone. Configuration drift between devices causes inconsistent behavior and difficult debugging. **When to use:** - You manage a fleet of edge devices running the same workload with differing local parameters - Edge devices have intermittent connectivity and must operate independently - You need a central source of truth for configuration with local overrides - Audit and compliance require tracking which configuration each device is running **WAF Pillars:** Operational Excellence **Related patterns:** External Configuration Store, Sidecar, Ambassador --- ### 16. Event Sourcing **Use an append-only store to record the full series of events that describe actions taken on data in a domain.** **Problem:** Traditional CRUD stores only keep current state—history is lost. Audit, debugging, temporal queries, and replays are impossible without supplementary logging, which is often incomplete or out of sync. **When to use:** - You need a complete, immutable audit trail of all changes - The business logic benefits from replaying or projecting events into different views - You want to decouple the write model from the read model (often combined with CQRS) - You need to reconstruct past states for debugging or regulatory purposes **WAF Pillars:** Reliability, Performance Efficiency **Related patterns:** CQRS, Materialized View, Compensating Transaction, Saga --- ### 17. External Configuration Store **Move configuration information out of the application deployment package to a centralized location.** **Problem:** Configuration files deployed alongside the application binary require redeployment to change. Different environments (dev, staging, prod) need different values. Sharing configuration across multiple services is difficult when each has its own config file. **When to use:** - Multiple services share common configuration settings - You need to update configuration without redeploying or restarting services - You want centralized access control and audit logging for configuration - Configuration must differ across environments but be managed in a single system **WAF Pillars:** Operational Excellence **Related patterns:** Edge Workload Configuration, Sidecar --- ### 18. Federated Identity **Delegate authentication to an external identity provider.** **Problem:** Building and maintaining your own identity store introduces security risks (password storage, credential rotation, MFA implementation). Users must manage separate credentials for each application, leading to password fatigue and weaker security posture. **When to use:** - Users already have identities in an enterprise directory or social provider - You want to enable single sign-on (SSO) across multiple applications - Business partners need to access your application with their own credentials - You want to offload identity management (MFA, password policy) to a specialized provider **WAF Pillars:** Reliability, Security, Performance Efficiency **Related patterns:** Gatekeeper, Valet Key, Gateway Offloading --- ### 19. Gatekeeper **Protect applications and services by using a dedicated host instance that acts as a broker between clients and the application or service.** **Problem:** Services that expose public endpoints are vulnerable to malicious attacks. Placing validation, authentication, and sanitization logic inside the service mixes security concerns with business logic and increases the attack surface if the service is compromised. **When to use:** - Applications handle sensitive data or high-value transactions - You need a centralized point for request validation and sanitization - You want to limit the attack surface by isolating security checks from the trusted host - Compliance requires an explicit security boundary between public and private tiers **WAF Pillars:** Security **Related patterns:** Valet Key, Gateway Routing, Gateway Offloading, Federated Identity --- ### 20. Gateway Aggregation **Use a gateway to aggregate multiple individual requests into a single request.** **Problem:** A client (especially mobile) may need data from multiple backend microservices to render a single page or view. Making many fine-grained calls from the client increases latency (multiple round trips), battery usage, and complexity. The client must understand the topology of the backend. **When to use:** - A client needs to make multiple calls to different backend services for a single operation - Network latency between the client and backend is significant (mobile, IoT, remote clients) - You want to reduce chattiness and simplify client code - Backend services are fine-grained microservices and the client should not know their topology **WAF Pillars:** Reliability, Security, Operational Excellence, Performance Efficiency **Related patterns:** Backends for Frontends, Gateway Offloading, Gateway Routing --- ### 21. Gateway Offloading **Offload shared or specialized service functionality to a gateway proxy.** **Problem:** Cross-cutting concerns such as TLS termination, authentication, rate limiting, logging, and compression are duplicated across every service. Each team must implement, configure, and maintain these features independently, leading to inconsistency and wasted effort. **When to use:** - Multiple services share cross-cutting concerns (TLS, auth, rate limiting, logging) - You want to standardize and centralize these features instead of duplicating them per service - You need to reduce operational complexity for individual service teams - The gateway is already in the request path and adding features there avoids extra hops **WAF Pillars:** Reliability, Security, Cost Optimization, Operational Excellence, Performance Efficiency **Related patterns:** Gateway Aggregation, Gateway Routing, Sidecar, Ambassador --- ### 22. Gateway Routing **Route requests to multiple services using a single endpoint.** **Problem:** Clients must know the addresses of multiple services. Adding, removing, or relocating a service requires client updates. Exposing internal service topology increases coupling and complicates DNS and load bal ... ``` ### `references/design-principles.md` ```markdown # Azure Design Principles Ten principles for building reliable, scalable, and manageable applications on Azure. | # | Principle | Focus | |---|-----------|-------| | 1 | [Design for self-healing](#1-design-for-self-healing) | Resilience & automatic recovery | | 2 | [Make all things redundant](#2-make-all-things-redundant) | Eliminate single points of failure | | 3 | [Minimize coordination](#3-minimize-coordination) | Scalability through decoupling | | 4 | [Design to scale out](#4-design-to-scale-out) | Horizontal scaling | | 5 | [Partition around limits](#5-partition-around-limits) | Overcome service boundaries | | 6 | [Design for operations](#6-design-for-operations) | Observability & automation | | 7 | [Use managed services](#7-use-managed-services) | Reduce operational burden | | 8 | [Use an identity service](#8-use-an-identity-service) | Centralized identity & access | | 9 | [Design for evolution](#9-design-for-evolution) | Change-friendly architecture | | 10 | [Build for the needs of business](#10-build-for-the-needs-of-business) | Align tech to business goals | --- ## 1. Design for self-healing Design the application to detect failures, respond gracefully, and recover automatically without manual intervention. ### Recommendations - **Implement retry logic with backoff** for transient failures in network calls, database connections, and external service interactions. - **Use health endpoint monitoring** to expose liveness and readiness probes so orchestrators and load balancers can route traffic away from unhealthy instances. - **Apply circuit breaker patterns** to prevent cascading failures — stop calling a failing dependency and allow it time to recover. - **Degrade gracefully** by serving reduced functionality (cached data, default responses) rather than failing entirely when a dependency is unavailable. - **Adopt chaos engineering** with Azure Chaos Studio to proactively inject faults and validate recovery paths before real incidents occur. ### Related design patterns | Pattern | Purpose | |---------|---------| | Retry | Handle transient faults by transparently retrying failed operations | | Circuit Breaker | Prevent repeated calls to a failing service | | Bulkhead | Isolate failures so one component doesn't take down others | | Health Endpoint Monitoring | Expose health checks for load balancers and orchestrators | | Leader Election | Coordinate distributed instances by electing a leader | | Throttling | Control resource consumption by limiting request rates | ### Azure services - **Azure Chaos Studio** — fault injection and chaos experiments - **Azure Monitor / Application Insights** — health monitoring, alerting, diagnostics - **Azure Traffic Manager / Front Door** — DNS and global failover - **Availability Zones** — zonal redundancy within a region --- ## 2. Make all things redundant Build redundancy into the application at every layer to avoid single points of failure. Composite availability formula: `1 - (1 - A)^N` where A is the availability of a single instance and N is the number of instances. ### Recommendations - **Place VMs behind a load balancer** and deploy multiple instances to ensure requests can be served even if one instance fails. - **Replicate databases** using read replicas, active geo-replication, or multi-region write to protect data and maintain read performance during outages. - **Use multi-zone and multi-region deployments** to survive datacenter and regional failures — define clear RTO (Recovery Time Objective) and RPO (Recovery Point Objective) targets. - **Partition workloads for availability** so that a failure in one partition doesn't affect others. - **Design for automatic failover** with health probes and traffic routing that redirects users without manual intervention. ### Related design patterns | Pattern | Purpose | |---------|---------| | Deployment Stamps | Deploy independent, identical copies of infrastructure | | Geode | Deploy backend services across geographies | | Health Endpoint Monitoring | Detect unhealthy instances for failover | | Queue-Based Load Leveling | Buffer requests to smooth demand spikes | ### Azure services - **Azure Load Balancer / Application Gateway** — distribute traffic across instances - **Azure SQL geo-replication / Cosmos DB multi-region** — database redundancy - **Availability Zones** — zonal redundancy within a region - **Azure Site Recovery** — disaster recovery orchestration - **Azure Front Door** — global load balancing with automatic failover --- ## 3. Minimize coordination Minimize coordination between application services to achieve scalability. Tightly coupled services that require synchronous calls create bottlenecks and reduce availability. ### Recommendations - **Embrace eventual consistency** instead of requiring strong consistency across services — accept that data may be temporarily out of sync. - **Use domain events and asynchronous messaging** to decouple producers and consumers so they can operate independently. - **Consider CQRS** (Command Query Responsibility Segregation) to separate read and write workloads with independently optimized stores. - **Design idempotent operations** so messages can be safely retried or delivered more than once without unintended side effects. - **Use optimistic concurrency** with version tokens or ETags instead of pessimistic locks that create coordination bottlenecks. ### Related design patterns | Pattern | Purpose | |---------|---------| | CQRS | Separate reads from writes for independent scaling | | Event Sourcing | Capture all changes as an immutable sequence of events | | Saga | Manage distributed transactions without two-phase commit | | Asynchronous Request-Reply | Decouple request and response across services | | Competing Consumers | Process messages in parallel across multiple consumers | ### Azure services - **Azure Service Bus** — reliable enterprise messaging with queues and topics - **Azure Event Grid** — event-driven routing at scale - **Azure Event Hubs** — high-throughput event streaming - **Azure Cosmos DB** — tunable consistency levels (eventual to strong) --- ## 4. Design to scale out Design the application so it can scale horizontally by adding or removing instances, rather than scaling up to larger hardware. ### Recommendations - **Avoid instance stickiness and session affinity** — store session state externally (Redis, database) so any instance can handle any request. - **Identify and resolve bottlenecks** that prevent horizontal scaling, such as shared databases, monolithic components, or stateful in-memory caches. - **Decompose workloads** into discrete services that can be scaled independently based on their specific demand profiles. - **Use autoscaling based on live metrics** (CPU, queue depth, request latency) rather than fixed schedules to match capacity to real demand. - **Design for scale-in** — handle instance removal gracefully with connection draining and proper shutdown hooks. ### Related design patterns | Pattern | Purpose | |---------|---------| | Competing Consumers | Distribute work across multiple consumers | | Sharding | Distribute data across partitions for parallel processing | | Deployment Stamps | Scale by deploying additional independent stamps | | Static Content Hosting | Offload static assets to reduce compute load | | Throttling | Protect the system from overload during scale events | ### Azure services - **Azure Virtual Machine Scale Sets** — autoscale VM pools - **Azure App Service / Azure Functions** — built-in autoscale - **Azure Kubernetes Service (AKS)** — horizontal pod autoscaler and cluster autoscaler - **Azure Cache for Redis** — externalize session state - **Azure CDN / Front Door** — offload static content delivery --- ## 5. Partition around limits Use partitioning to work around database, network, and compute limits. Every Azure service has limits — partitioning allows you to scale beyond them. ### Recommendations - **Partition databases** horizontally (sharding), vertically (splitting columns), or functionally (by bounded context) to distribute load and storage. - **Design partition keys to avoid hotspots** — choose keys that distribute data and traffic evenly across partitions. - **Partition at different levels** — database, queue, network, and compute — to address bottlenecks wherever they occur. - **Understand service-specific limits** for throughput, connections, storage, and request rates and design partitioning strategies accordingly. ### Related design patterns | Pattern | Purpose | |---------|---------| | Sharding | Distribute data across multiple databases or partitions | | Priority Queue | Process high-priority work before lower-priority work | | Queue-Based Load Leveling | Buffer writes to smooth spikes | | Valet Key | Grant limited direct access to resources | ### Azure services - **Azure Cosmos DB** — automatic partitioning with configurable partition keys - **Azure SQL Elastic Pools** — manage and scale multiple databases - **Azure Storage** — table, blob, and queue partitioning - **Azure Service Bus** — partitioned queues and topics --- ## 6. Design for operations Design the application so that the operations team has the tools they need to monitor, diagnose, and manage it in production. ### Recommendations - **Instrument everything** with structured logging, distributed tracing, and metrics to make the system observable from day one. - **Use distributed tracing** with correlation IDs that flow across service boundaries to diagnose issues in microservices architectures. - **Automate operational tasks** — deployments, scaling, failover, and routine maintenance should require no manual steps. - **Treat configuration as code** — store all environment configuration in version control and deploy it through the same CI/CD pipelines as application code. - **Implement dashboards and alerts** that surface actionable information, not just raw data, so operators can respond quickly. ### Related design patterns | Pattern | Purpose | |---------|---------| | Health Endpoint Monitoring | Expose operational health for monitoring tools | | Ambassador | Offload cross-cutting concerns like logging and monitoring | | Sidecar | Deploy monitoring agents alongside application containers | | External Configuration Store | Centralize configuration management | ### Azure services - **Azure Monitor** — metrics, logs, and alerts across all Azure resources - **Application Insights** — application performance monitoring and distributed tracing - **Azure Log Analytics** — centralized log querying with KQL - **Azure Resource Manager (ARM) / Bicep** — infrastructure as code - **Azure DevOps / GitHub Actions** — CI/CD pipelines --- ## 7. Use managed services Prefer platform as a service (PaaS) over infrastructure as a service (IaaS) wherever possible to reduce operational overhead. ### Recommendations - **Default to PaaS** for compute, databases, messaging, and storage — let Azure handle OS patching, scaling, and high availability. - **Use IaaS only when you need fine-grained control** over the operating system, runtime, or network configuration that PaaS cannot provide. - **Leverage built-in scaling and redundancy** features of managed services instead of building and maintaining them yourself. ### Related design patterns | Pattern | Purpose | |---------|---------| | Backends for Frontends | Use managed API gateways per client type | | Gateway Aggregation | Aggregate calls through a managed gateway | | Static Content Hosting | Use managed storage for static assets | ### Azure services | IaaS | PaaS Alternative | |------|-------------------| | VMs with IIS/Nginx | Azure App Service | | VMs with SQL Server | Azure SQL Database | | VMs with RabbitMQ | Azure Service Bus | | VMs with Kubernetes | Azure Kubernetes Service (AKS) | | VMs with custom functions | Azure Functions | | VMs with Redis | Azure Cache for Redis | | VMs with Elasticsearch | Azure AI Search | --- ## 8. Use an identity service Use a centralized identity platform instead of building or managing your own authentication and authorization system. ### Recommendations - **Use Microsoft Entra ID** (formerly Azure AD) as the single identity provider for users, applications, and service-to-service authentication. - **Never store credentials in application code or configuration** — use managed identities, certificate-based auth, or federated credentials. - **Implement federation protocols** (SAML, OIDC, OAuth 2.0) to integrate with external identity providers and enable single sign-on. - **Adopt modern security features** — passwordless authentication (FIDO2, Windows Hello), conditional access policies, multi-factor authentication (MFA), and single sign-on (SSO). - **Use managed identities for Azure resources** to eliminate credential management for service-to-service communication entirely. ### Related design patterns | Pattern | Purpose | |---------|---------| | Federated Identity | Delegate authentication to an external identity provider | | Gatekeeper | Protect backends by validating identity at the edge | | Valet Key | Grant scoped, time-limited access to resources | ### Azure services - **Microsoft Entra ID** — cloud identity and access management - **Azure Managed Identities** — credential-free service-to-service auth - **Azure Key Vault** — secrets, certificates, and key management - **Microsoft Entra External ID** — customer and partner identity (B2C/B2B) --- ## 9. Design for evolution Design the architecture so it can evolve over time as requirements, technologies, and team understanding change. ### Recommendations - **Enforce loose coupling and high cohesion** — services should expose well-defined interfaces and encapsulate their internal implementation details. - **Encapsulate domain knowledge** within service boundaries so changes to business logic don't ripple across the system. - **Use asynchronous messaging** between services to reduce temporal coupling — services don't need to be available at the same time. - **Version APIs** from day one so clients can migrate at their own pace and you can evolve without breaking existing consumers. - **Deploy services independently** with their own release cadence — avoid coordinated "big bang" deployments. ### Related design patterns | Pattern | Purpose | |---------|---------| | Anti-Corruption Layer | Isolate new services from legacy systems | | Strangler Fig | Incrementally migrate a monolith to microservices | | Backends for Frontends | Evolve APIs independently per client type | | Gateway Routing | Route requests to different service versions | ### Azure services - **Azure API Management** — API versioning, routing, and lifecycle management - **Azure Kubernetes Service (AKS)** — independent service deployments with rolling updates - **Azure Service Bus** — asynchronous inter-service messaging - **Azure Container Apps** — revision-based deployments with traffic splitting --- ## 10. Build for the needs of business Every design decision must be justified by a business requirement. Align technical choices with business goals, constraints, and growth plans. ### Recommendations - **Define RTO, RPO, and MTO** (Recovery Time Objective, Recovery Point Objective, Maximum Tolerable Outage) for each workload based on business impact analysis. - **Document SLAs and SLOs** — understand the composite SLA of your architecture and set internal SLOs that provide an error budget for engineering work. - **Model the system around the business domain** using domain-driven design to ensure the architecture reflects how the business operates. - **Define functional and nonfunctional requirements explicitly** — capture performance targets, compliance needs, data residency constraints, and user experience expectations. - **Plan for growth** — design capacity models that account for business projections, seasonal peaks, and market expansion. ### Related design patterns | Pattern | Purpose | |---------|---------| | Priority Queue | Process business-critical work first | | Throttling | Protect SLOs under heavy load | | Deployment Stamps | Scale to new markets and regions | | Bulkhead | Isolate critical workloads from non-critical ones | ### Azure services - **Azure Advisor** — cost, performance, reliability, and security recommendations - **Azure Cost Management** — budget tracking and cost optimization - **Azure Service Health** — SLA tracking and incident awareness - **Azure Well-Architected Framework Review** — assess architecture against best practices - **Azure Monitor SLO/SLI dashboards** — measure and track service level objectives --- > Source: [Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/) ``` ### `references/mission-critical.md` ```markdown # Mission-Critical Architecture on Azure Guidance for designing mission-critical workloads on Azure that prioritize cloud-native capabilities to maximize reliability and operational effectiveness. **Target SLO:** **99.99%** or higher — permitted annual downtime: **52 minutes 35 seconds**. All encompassed design decisions are intended to accomplish this target SLO. | SLO Target | Permitted Annual Downtime | Typical Use Case | |---|---|---| | 99.9% | 8 hours 45 minutes | Standard business apps | | 99.95% | 4 hours 22 minutes | Important business apps | | 99.99% | 52 minutes 35 seconds | Mission-critical workloads | | 99.999% | 5 minutes 15 seconds | Safety-critical systems | --- ## Key Design Strategies ### 1. Redundancy in Layers Deploy redundancy at every layer of the architecture to eliminate single points of failure. - Deploy to multiple regions in an **active-active** model — application distributed across 2+ Azure regions handling active user traffic simultaneously - Utilize **availability zones** for all considered services — distributing components across physically separate datacenters inside a region - Choose resources that support **global distribution** natively - Apply zone-redundant configurations for all stateful services - Ensure data replication meets RPO requirements across regions **Azure services:** Azure Front Door (global routing), Azure Traffic Manager (DNS failover), Azure Cosmos DB (multi-region writes), Azure SQL (geo-replication) ### 2. Deployment Stamps Deploy regional stamps as scale units — a logical set of resources that can be independently provisioned to keep up with demand changes. - Each stamp is a **self-contained scale unit** with its own compute, caching, and local state - Multiple nested scale units within a stamp (e.g., Frontend APIs and Background processors scale independently) - **No dependencies between scale units** — they only communicate with shared services outside the stamp - Scale units are **temporary/ephemeral** — store persistent system-of-record data only in the replicated database - Use stamps for blue-green deployments by rolling out new units, validating, and gradually shifting traffic **Key benefit:** Compartmentalization enables independent scaling and fault isolation per region. ### 3. Reliable and Repeatable Deployments Apply the principle of Infrastructure as Code (IaC) for version control and standardized operations. - Use **Terraform** or **Bicep** for infrastructure definition with version control - Implement **zero-downtime blue/green deployment** pipelines — build and release pipelines fully automated - Apply **environment consistency** — use the same deployment pipeline code across production and pre-production environments - Integrate **continuous validation** — automated testing as part of DevOps processes - Include synchronized **load and chaos testing** to validate both application code and underlying infrastructure - Deploy stamps as a **single operational unit** — never partially deploy a stamp ### 4. Operational Insights Build comprehensive observability without introducing single points of failure. - Use **federated workspaces** for observability data — monitoring data for global and regional resources stored independently - A centralized observability store is **NOT recommended** (it becomes a single point of failure) - Use **cross-workspace querying** to achieve a unified data sink and single pane of glass for operations - Construct a **layered health model** mapping application health to a traffic light model for contextualizing - Health scores calculated for each **individual component**, then **aggregated at user flow level** - Combine with key non-functional requirements (performance) as coefficients to quantify application health --- ## Design Areas Each design area must be addressed for a mission-critical architecture. | Design Area | Description | Key Concerns | |---|---|---| | **Application platform** | Infrastructure choices and mitigations for potential failure cases | AKS vs App Service, availability zones, containerization | | **Application design** | Design patterns that allow for scaling and error handling | Stateless services, async messaging, queue-based decoupling | | **Networking and connectivity** | Network considerations for routing incoming traffic to stamps | Global load balancing, WAF, DDoS protection, private endpoints | | **Data platform** | Choices in data store technologies | Volume, velocity, variety, veracity; active-active vs active-passive | | **Deployment and testing** | Strategies for CI/CD pipelines and automation | Blue/green deployments, load testing, chaos testing | | **Health modeling** | Observability through customer impact analysis | Correlated monitoring, traffic light model, health scores | | **Security** | Mitigation of attack vectors | Microsoft Zero Trust model, identity-based access, encryption | | **Operational procedures** | Processes related to runtime operations | Deployment SOPs, key management, patching, incident response | --- ## Active-Active Multi-Region Architecture The core topology for mission-critical workloads distributes the application across multiple Azure regions. ### Architecture Characteristics - Application distributed across **2+ Azure regions** handling active user traffic simultaneously - Each region contains independent **deployment stamps** (scale units) - **Azure Front Door** provides global routing, SSL termination, and WAF at the edge - Scale units have **no cross-dependencies** — they communicate only with shared services (e.g., global database, DNS) - Persistent data resides only in the **replicated database** — stamps store no durable local state - When scale units are replaced or retired, applications reconnect transparently ### Data Replication Strategies | Strategy | Writes | Reads | Consistency | Best For | |---|---|---|---|---| | Active-passive (Azure SQL) | Single primary region | All regions via read replicas | Strong | Relational data, ACID transactions | | Active-active (Cosmos DB) | All regions | All regions | Tunable (5 levels) | Document/key-value data, global apps | | Write-behind (Redis → SQL) | Redis first, async to SQL | Redis or SQL | Eventual | High-throughput writes, rate limiting | ### Regional Stamp Composition Each stamp typically includes: - **Compute tier** — App Service or AKS with multiple instances across availability zones - **Caching tier** — Azure Managed Redis for session state, rate limiting, feature flags - **Configuration** — Azure App Configuration for settings (capacity correlates with requests/second) - **Secrets** — Azure Key Vault for certificates and secrets - **Networking** — Virtual network with private endpoints, NSGs, and service endpoints --- ## Health Modeling and Traffic Light Approach Health modeling provides the foundation for automated operational decisions. ### Building the Health Model 1. **Identify user flows** — map critical paths through the application (e.g., "user login", "checkout", "search") 2. **Decompose into components** — each flow depends on specific compute, data, and network components 3. **Assign health scores** — each component reports a health score based on metrics (latency, error rate, saturation) 4. **Aggregate per flow** — combine component scores weighted by criticality to produce a flow-level health score 5. **Apply traffic light** — map aggregate scores to **Green** (healthy), **Yellow** (degraded), **Red** (unhealthy) ### Health Score Coefficients | Factor | Metric Examples | Weight Guidance | |---|---|---| | Availability | Error rate, HTTP 5xx ratio | High — directly impacts users | | Performance | P95 latency, request duration | Medium — affects user experience | | Saturation | CPU %, memory %, queue depth | Medium — indicates future problems | | Freshness | Data replication lag, cache age | Lower — depends on consistency needs | ### Operational Actions by Health State | State | Meaning | Automated Action | |---|---|---| | 🟢 Green | All components healthy | Normal operations | | 🟡 Yellow | Degraded but functional | Alert on-call, increase monitoring frequency | | 🔴 Red | Critical failure detected | Trigger failover, page on-call, block deployments | --- ## Zero-Downtime Deployment (Blue/Green) Deployment must never cause downtime in a mission-critical system. ### Blue/Green Process 1. **Provision new stamp** — deploy a complete new scale unit ("green") alongside the existing one ("blue") 2. **Run validation** — execute automated smoke tests, integration tests, and synthetic transactions against the green stamp 3. **Canary traffic** — route a small percentage of production traffic (e.g., 5%) to the green stamp 4. **Monitor health** — compare health scores between blue and green stamps over a defined observation period 5. **Gradual shift** — increase traffic to green stamp in increments (5% → 25% → 50% → 100%) 6. **Decommission blue** — once green is fully validated, tear down the blue stamp ### Key Requirements - Build and release pipelines must be **fully automated** — no manual deployment steps - Use the **same pipeline code** for all environments (dev, staging, production) - Each stamp deployed as a **single operational unit** — never partial - Rollback is achieved by **shifting traffic back** to the previous stamp (still running during validation) - **Continuous validation** runs throughout the deployment, not just at the end --- ## Chaos Engineering and Continuous Validation Proactive failure testing ensures recovery mechanisms work before real incidents occur. ### Chaos Engineering Practices - Use **Azure Chaos Studio** to run controlled experiments against production or pre-production environments - Test failure modes: availability zone outage, network partition, dependency failure, CPU/memory pressure - Run chaos experiments as part of the **CI/CD pipeline** — every deployment is validated under fault conditions - **Synchronized load and chaos testing** — inject faults while the system is under realistic load ### Validation Checklist - [ ] Health model detects injected faults within SLO-defined time windows - [ ] Automated failover completes within target RTO - [ ] No data loss exceeding target RPO during regional failover - [ ] Application degrades gracefully (reduced functionality, not total failure) - [ ] Alerts fire correctly and reach the on-call team - [ ] Runbooks and automated remediation execute successfully --- ## Application Platform Considerations ### Platform Options | Platform | Best For | Availability Zone Support | Complexity | |---|---|---|---| | **Azure App Service** | Web apps, APIs, PaaS-first approach | Yes (zone-redundant) | Low-Medium | | **AKS** | Complex microservices, full K8s control | Yes (zone-redundant node pools) | High | | **Container Apps** | Serverless containers, event-driven | Yes | Medium | ### Recommendations - **Prioritize availability zones** for all production workloads — spread across physically separate datacenters - **Containerize workloads** for reliability and portability between platforms - Ensure all services in a scale unit support availability zones — don't mix zonal and non-zonal services - For latency-sensitive or chatty workloads, consider tradeoffs of cross-zone traffic cost and latency --- ## Data Platform Considerations ### Choosing a Primary Database | Scenario | Recommended Service | Deployment Model | |---|---|---| | Relational data, ACID transactions | **Azure SQL** | Active-passive with geo-replication | | Global distribution, multi-model | **Azure Cosmos DB** | Active-active with multi-region writes | | Multiple microservice databases | **Mixed (polyglot)** | Per-service database with appropriate model | ### Azure SQL in Mission-Critical - Azure SQL does **not** natively support active-active concurrent writes in multiple regions - Use **active-passive** strategy: single primary region for writes, read replicas in secondary regions - **Partial active-active** possible at the application tier — route reads to local replicas, writes to primary - Configure **auto-failover groups** for automated regional failover ### Azure Managed Redis in Mission-Critical - Use within or alongside each scale unit for: - **Cache data** — rebuildable, repopulated on demand - **Session state** — user sessions during scale unit lifetime - **Rate limit counters** — per-user and per-tenant throttling - **Feature flags** — dynamic configuration without redeployment - **Coordination metadata** — distributed locks, leader election - **Active geo-replication** enables Redis data to replicate asynchronously across regions - Design cached data as either **rebuildable** (repopulate without availability impact) or **durable auxiliary state** (protected by persistence and geo-replication) --- ## Security in Mission-Critical ### Zero Trust Principles - **Verify explicitly** — authenticate and authorize based on all available data points (identity, location, device, service) - **Use least privilege access** — limit user access with Just-In-Time and Just-Enough-Access (JIT/JEA) - **Assume breach** — minimize blast radius and segment access, verify end-to-end encryption, use analytics for threat detection ### Security Controls | Layer | Control | Azure Service | |---|---|---| | Edge | DDoS protection, WAF | Azure Front Door, Azure DDoS Protection | | Identity | Managed identities, RBAC | Microsoft Entra ID, Azure RBAC | | Network | Private endpoints, NSGs | Azure Private Link, Virtual Network | | Data | Encryption at rest and in transit | Azure Key Vault, TDE, TLS 1.2+ | | Operations | Privileged access management | Microsoft Entra PIM, Azure Bastion | --- ## Operational Procedures ### Key Operational Processes | Process | Description | Automation Level | |---|---|---| | **Deployment** | Blue/green with automated validation | Fully automated | | **Scaling** | Stamp provisioning and decommissioning | Automated with manual approval gates | | **Key rotation** | Certificate and secret rotation | Automated via Key Vault policies | | **Patching** | OS and runtime updates | Automated via platform (PaaS) or pipeline (IaaS) | | **Incident response** | Detection, triage, mitigation, resolution | Semi-automated (alert → runbook → human) | | **Capacity planning** | Forecast demand, pre-provision stamps | Manual with data-driven analysis | ### Runbook Requirements - All operational runbooks must be **tested in pre-production** with the same chaos/load scenarios as production - **Automated remediation** preferred over manual intervention for known failure modes - Runbooks must include **rollback procedures** for every change type - **Post-incident reviews** (blameless) must feed back into health model and chaos experiment improvements --- > Source: [Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/) ``` ### `references/performance-antipatterns.md` ```markdown # Performance Antipatterns Ten common performance antipatterns in cloud applications and how to resolve them. --- ## 1. Busy Database **Description:** Offloading too much processing to a data store. Using stored procedures for formatting, string manipulation, or complex calculations that belong in the application tier. **Why it happens:** - Database viewed as a service rather than a repository - Developers write queries that format data for direct display - Attempts to correct Extraneous Fetching by pushing compute to the database **Symptoms:** - Disproportionate decline in throughput and response times for database operations **How to detect:** - Performance monitoring of database activity - Examine work performed during slow periods **How to fix:** - Move processing (formatting, string manipulation, calculations) to application tiers - Limit the database to data access operations (aggregation is acceptable) - Don't move processing out if it causes the database to transfer far more data (Extraneous Fetching) **Example scenario:** A SQL query performs XML formatting, string concatenation, and locale-specific formatting in T-SQL instead of returning raw data and letting application code handle presentation. --- ## 2. Busy Front End **Description:** Moving resource-intensive tasks onto foreground/UI threads instead of background threads. **Why it happens:** - Processing done synchronously in request handlers **Symptoms:** - High latency on requests - Poor user responsiveness **How to detect:** - Monitor thread utilization and CPU usage on the front-end tier **How to fix:** - Move resource-intensive tasks to background threads or services (Azure Functions, WebJobs) **Example scenario:** A web API controller performs image resizing synchronously within the HTTP request pipeline, blocking the thread and causing timeouts for other users during peak load. --- ## 3. Chatty I/O **Description:** Continually sending many small network requests instead of fewer larger ones. **Why it happens:** - Following object-oriented patterns that make many small calls - Individual property gets instead of batch reads **Symptoms:** - High number of I/O operations - High latency due to network round trips **How to detect:** - Monitor the number of I/O requests and their sizes **How to fix:** - Bundle multiple smaller requests into fewer larger ones - Use caching to avoid repeated calls - Read data in bulk **Example scenario:** An application retrieves a user profile by making separate API calls for name, email, address, and preferences instead of a single call that returns the complete profile object. --- ## 4. Extraneous Fetching **Description:** Retrieving more data than needed, resulting in unnecessary I/O and memory consumption. **Why it happens:** - `SELECT *` queries - Fetching all columns or rows when only a subset is needed **Symptoms:** - High memory usage - Excessive bandwidth consumption **How to detect:** - Profile queries and check data transfer sizes **How to fix:** - Request only needed data columns and rows - Use pagination and projections **Example scenario:** An order history page runs `SELECT * FROM Orders` and filters in application code, transferring millions of rows when the user only sees the 20 most recent orders. --- ## 5. Improper Instantiation **Description:** Repeatedly creating and destroying objects designed to be shared and reused, such as `HttpClient`, database connections, or service clients. **Why it happens:** - Not understanding object lifecycle - Creating new instances per request **Symptoms:** - Port exhaustion - Socket exhaustion - Connection pool depletion **How to detect:** - Monitor connection counts, socket usage, and object creation rates **How to fix:** - Use singleton or static instances for shared clients - Use connection pooling - Use `IHttpClientFactory` for HTTP clients **Example scenario:** A web application creates a new `HttpClient` instance for every incoming request. Under load, available sockets are exhausted and requests fail with `SocketException` errors. --- ## 6. Monolithic Persistence **Description:** Using one data store for data with very different usage patterns. **Why it happens:** - Simplicity of a single database - Legacy design decisions **Symptoms:** - Performance degradation as different workloads compete for the same resources **How to detect:** - Monitor data store metrics and identify competing access patterns **How to fix:** - Separate data by usage pattern into appropriate stores (hot/warm/cold) - Apply polyglot persistence — use the right store for each data type **Example scenario:** A single SQL database handles both high-throughput transactional writes and complex analytical reporting queries, causing lock contention that degrades both workloads. --- ## 7. No Caching **Description:** Failing to cache frequently accessed data that changes infrequently. **Why it happens:** - Not considering a caching strategy - Assuming the database can handle all read traffic **Symptoms:** - Repeated identical queries - High database load - Slow response times **How to detect:** - Monitor cache hit ratios and look for repeated identical queries **How to fix:** - Implement the Cache-Aside pattern - Use Azure Cache for Redis - Set appropriate TTLs based on data volatility **Example scenario:** A product catalog page queries the database on every page load for data that only changes once a day, generating thousands of identical queries per hour. --- ## 8. Noisy Neighbor **Description:** A single tenant consumes a disproportionate amount of shared resources, starving other tenants. **Why it happens:** - Multi-tenant systems without resource isolation or throttling **Symptoms:** - Other tenants experience degraded performance - Resource starvation for well-behaved tenants **How to detect:** - Monitor per-tenant resource usage and identify outliers **How to fix:** - Implement tenant isolation, throttling, and quotas - Use the Bulkhead pattern to partition resources - Separate compute per tenant if needed **Example scenario:** In a shared SaaS platform, one tenant runs a bulk data import that saturates the database connection pool, causing timeout errors for all other tenants. --- ## 9. Retry Storm **Description:** Retrying failed requests too aggressively, amplifying failures during outages. **Why it happens:** - Aggressive retry policies without backoff - All clients retry simultaneously (thundering herd) **Symptoms:** - Cascading failures - Overwhelming services that are trying to recover **How to detect:** - Monitor retry rates and correlate with service recovery time **How to fix:** - Use exponential backoff with jitter - Implement the Circuit Breaker pattern - Cap retry attempts **Example scenario:** A downstream service goes offline for 30 seconds. Hundreds of clients immediately retry every 100ms with no backoff, generating 10x normal traffic and preventing the service from recovering for several minutes. --- ## 10. Synchronous I/O **Description:** Blocking the calling thread while I/O completes. **Why it happens:** - Using synchronous APIs for network or disk operations **Symptoms:** - Thread pool exhaustion - Poor scalability under load - UI freezing in client applications **How to detect:** - Monitor thread pool usage and identify blocking calls **How to fix:** - Use `async`/`await` patterns - Use non-blocking I/O and async APIs **Example scenario:** A web API makes synchronous HTTP calls to three downstream services sequentially. Under load, all thread pool threads are blocked waiting for responses, and the server can no longer accept new requests. --- > Source: [Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/) ``` ### `references/technology-choices.md` ```markdown # Azure Technology Choice Decision Frameworks Decision frameworks for selecting the right Azure service in each category. Use these tables to compare options based on scale, cost, complexity, and use case fit. ## Decision Approach 1. **Start with requirements** — workload type, scale needs, team expertise 2. **Use the comparison tables** — narrow to 2-3 candidates 3. **Follow the decision trees** — Azure Architecture Center provides flowcharts for compute, data store, load balancing, and messaging 4. **Validate with constraints** — budget, compliance, regional availability, existing infrastructure --- ## 1. Compute Choose a compute service based on control needs, scaling model, and operational complexity. | Service | Best For | Scale | Complexity | Cost Model | |---|---|---|---|---| | Azure VMs | Full control, lift-and-shift, custom OS | Manual/VMSS | High | Per-hour | | App Service | Web apps, APIs, mobile backends | Built-in autoscale | Low | Per App Service plan | | Azure Functions | Event-driven, short-lived processes | Consumption-based auto | Very Low | Per execution | | AKS | Microservices, complex orchestration | Node/pod autoscaling | High | Per node VM | | Container Apps | Serverless containers, microservices | KEDA-based autoscale | Medium | Per vCPU/memory/s | | Container Instances | Simple containers, batch jobs | Per-instance | Very Low | Per second | **Quick decision:** - Need full OS control? → **VMs** - Web app or API with minimal ops? → **App Service** - Short-lived event-driven code? → **Functions** - Complex microservices with K8s expertise? → **AKS** - Microservices without K8s management? → **Container Apps** - Run a container quickly, no orchestration? → **Container Instances** --- ## 2. Storage Choose a storage service based on data structure, access patterns, and scale. | Service | Best For | Access Pattern | Scale | Cost | |---|---|---|---|---| | Blob Storage | Unstructured data, media, backups | REST API, SDK | Massive | Per GB + operations | | Azure Files | SMB/NFS file shares, lift-and-shift | File system mount | TB-scale | Per GB provisioned | | Queue Storage | Simple message queuing | Pull-based | High throughput | Very low per message | | Table Storage | NoSQL key-value data | REST API | TB-scale | Per GB + operations | | Data Lake Storage | Big data analytics, hierarchical namespace | ABFS, REST | Massive | Per GB, tiered | **Quick decision:** - Blobs, images, videos, backups? → **Blob Storage** - Need a mounted file share (SMB/NFS)? → **Azure Files** - Simple async message queue? → **Queue Storage** - Key-value NoSQL without Cosmos DB cost? → **Table Storage** - Big data analytics with hierarchical namespace? → **Data Lake Storage** --- ## 3. Database Choose a database based on data model, consistency needs, and scale requirements. | Service | Best For | Consistency | Scale | Cost Model | |---|---|---|---|---| | Azure SQL | Relational, OLTP, enterprise apps | Strong (ACID) | Up to Hyperscale | DTU or vCore-based | | Cosmos DB | Global distribution, multi-model, low latency | Tunable (5 levels) | Unlimited horizontal | RU/s + storage | | Azure Database for PostgreSQL | Open-source relational, PostGIS, JSON | Strong (ACID) | Flexible Server auto | vCore-based | | Azure Database for MySQL | Open-source relational, web apps | Strong (ACID) | Flexible Server auto | vCore-based | **Quick decision:** - Enterprise SQL Server workloads? → **Azure SQL** - Global distribution or single-digit-ms latency? → **Cosmos DB** - Open-source relational with spatial/JSON? → **PostgreSQL** - Open-source relational for web apps? → **MySQL** --- ## 4. Messaging Choose a messaging service based on delivery guarantees, throughput, and integration pattern. | Service | Best For | Delivery | Throughput | Cost | |---|---|---|---|---| | Service Bus | Enterprise messaging, ordered delivery, transactions | At-least-once, at-most-once | Moderate-high | Per operation + unit | | Event Hubs | Event streaming, telemetry, big data ingestion | At-least-once, partitioned | Very high (millions/s) | Per TU/PU + ingress | | Event Grid | Event-driven reactive programming, webhooks | At-least-once | High | Per operation | | Queue Storage | Simple async messaging, decoupling | At-least-once | Moderate | Very low per message | **Quick decision:** - Enterprise messaging with ordering/transactions? → **Service Bus** - High-volume event streaming or telemetry? → **Event Hubs** - Reactive event routing (resource events, webhooks)? → **Event Grid** - Simple, cheap async decoupling? → **Queue Storage** --- ## 5. Networking Choose a load balancing service based on traffic scope, protocol layer, and feature needs. | Service | Best For | Scope | Layer | Features | |---|---|---|---|---| | Azure Front Door | Global HTTP(S) load balancing, CDN, WAF | Global | Layer 7 | CDN, WAF, SSL offload, caching | | Application Gateway | Regional HTTP(S) load balancing, WAF | Regional | Layer 7 | WAF, URL routing, SSL termination | | Azure Load Balancer | TCP/UDP traffic distribution | Regional | Layer 4 | High perf, zone redundant | | Traffic Manager | DNS-based global traffic routing | Global | DNS | Failover, performance, geographic routing | **Quick decision:** - Global HTTP(S) with CDN and WAF? → **Front Door** - Regional HTTP(S) with WAF? → **Application Gateway** - Regional TCP/UDP load balancing? → **Load Balancer** - DNS-based global failover? → **Traffic Manager** --- ## 6. AI Services Choose an AI service based on customization needs and model type. | Service | Best For | Complexity | Scale | |---|---|---|---| | Azure OpenAI | LLMs, GPT models, generative AI | Medium | API-based, token pricing | | Azure AI Services | Pre-built AI (vision, speech, language) | Low | API-based, per transaction | | Azure Machine Learning | Custom ML models, MLOps, training | High | Compute cluster-based | **Quick decision:** - Need GPT/LLM capabilities? → **Azure OpenAI** - Pre-built vision, speech, or language? → **AI Services** - Custom model training and MLOps? → **Azure Machine Learning** --- ## 7. Containers Choose a container service based on orchestration needs and operational complexity. | Service | Best For | Orchestration | Complexity | Cost | |---|---|---|---|---| | AKS | Full Kubernetes, complex workloads | Full K8s control plane | High | Per node VM | | Container Apps | Serverless containers, microservices, event-driven | Managed (built on K8s) | Medium | Per vCPU/memory/s | | Container Instances | Simple containers, sidecar groups, batch | None (per-instance) | Very Low | Per second | **Quick decision:** - Need full Kubernetes API and control? → **AKS** - Serverless containers with event-driven scaling? → **Container Apps** - Run a single container or batch job quickly? → **Container Instances** --- ## Related Decision Trees The Azure Architecture Center provides detailed flowcharts for these decisions: - [Choose a compute service](https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/compute-decision-tree) - [Compare Container Apps with other options](https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/compute-decision-tree#compare-container-options) - [Choose a data store](https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/data-store-overview) - [Load balancing decision tree](https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/load-balancing-overview) - [Compare messaging services](https://learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/messaging) > Source: [Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/) ```