Cross-Pillar Design Patterns

TL;DR

Real-world architectures require balancing multiple pillars simultaneously. This chapter covers:

• Cross-pillar patterns: Designs that address multiple concerns
• Tradeoff analysis: Understanding pillar interactions
• Reference architectures: Proven patterns for common scenarios
• Anti-patterns: Common mistakes to avoid
• Decision frameworks: Making informed architectural choices

---

Understanding Tradeoffs

Pillar Interaction Matrix

Every architectural decision affects multiple pillars. Understanding these interactions helps make informed tradeoffs.

Tradeoff Matrix

Decision	Reliability	Security	Cost	Operations	Performance
Add geo-redundancy	↑↑	→	↓↓	↓	→
Enable encryption	→	↑↑	↓	→	↓
Use premium storage	↑	→	↓↓	→	↑↑
Implement caching	↑	↓	↓	↓	↑↑
Add monitoring	↑	↑	↓	↑↑	→
Use serverless	↑	→	↑	↑	→
Use spot VMs	↓↓	→	↑↑	↓	→

Legend: ↑↑ Strong positive | ↑ Positive | → Neutral | ↓ Negative | ↓↓ Strong negative

---

Cross-Pillar Patterns

Pattern 1: Resilient and Secure API

Combines reliability and security patterns for production APIs.

Pillars Addressed:

• Reliability: Multi-zone AKS, geo-replicated SQL, caching
• Security: WAF, DDoS protection, API authentication, rate limiting
• Performance: CDN, caching, optimized data access
• Operations: Managed services, built-in monitoring

Implementation Highlights:

// Bicep - Front Door with WAF
resource frontDoor 'Microsoft.Cdn/profiles@2023-05-01' = {
  name: 'fd-api'
  location: 'global'
  sku: { name: 'Premium_AzureFrontDoor' }
}

resource wafPolicy 'Microsoft.Network/FrontDoorWebApplicationFirewallPolicies@2022-05-01' = {
  name: 'waf-policy'
  location: 'global'
  properties: {
    policySettings: {
      mode: 'Prevention'
      enabledState: 'Enabled'
    }
    managedRules: {
      managedRuleSets: [
        { ruleSetType: 'Microsoft_DefaultRuleSet', ruleSetVersion: '2.1' }
        { ruleSetType: 'Microsoft_BotManagerRuleSet', ruleSetVersion: '1.0' }
      ]
    }
  }
}

---

Pattern 2: Cost-Optimized High Availability

Achieves high availability while managing costs.

Cost Optimization Strategies:

• Secondary region uses lower SKUs during normal operation
• Auto-scale secondary on failover
• Use geo-replication instead of active-active
• Reserved instances for primary region only

Pillars Addressed:

• Reliability: Geo-redundancy, automated failover
• Cost: Right-sized secondary, reserved capacity
• Operations: Automated scaling on failover

---

Pattern 3: Secure Data Pipeline

End-to-end security for data processing with performance optimization.

Security Controls:

• All services use private endpoints
• Data encrypted at rest and in transit
• Managed identities for service-to-service auth
• Network isolation with VNet integration

Performance Optimizations:

• Partitioned data ingestion
• Delta Lake for efficient updates
• Synapse dedicated pools for analytics
• Caching in Power BI

---

Pattern 4: Observable Microservices

Full observability stack for distributed systems.

Observability Components:

// C# - Distributed tracing with OpenTelemetry
builder.Services.AddOpenTelemetry()
    .WithTracing(tracing =>
    {
        tracing
            .AddAspNetCoreInstrumentation()
            .AddHttpClientInstrumentation()
            .AddSqlClientInstrumentation()
            .AddSource("MyApp")
            .AddAzureMonitorTraceExporter(options =>
            {
                options.ConnectionString = config["ApplicationInsights:ConnectionString"];
            });
    })
    .WithMetrics(metrics =>
    {
        metrics
            .AddAspNetCoreInstrumentation()
            .AddHttpClientInstrumentation()
            .AddAzureMonitorMetricExporter();
    });

---

Pattern 5: Zero-Downtime Deployment

Safe deployment pattern balancing speed and reliability.

Implementation:

# GitHub Actions - Blue-green deployment
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to staging slot
        uses: azure/webapps-deploy@v3
        with:
          app-name: myapp
          slot-name: staging
          package: ./publish
      
      - name: Validate staging
        run: |
          for i in {1..10}; do
            status=$(curl -s -o /dev/null -w "%{http_code}" https://myapp-staging.azurewebsites.net/health)
            if [ "$status" = "200" ]; then
              echo "Health check passed"
              exit 0
            fi
            sleep 10
          done
          echo "Health check failed"
          exit 1
      
      - name: Swap slots
        uses: azure/CLI@v1
        with:
          inlineScript: |
            az webapp deployment slot swap \
              --name myapp \
              --resource-group myRG \
              --slot staging \
              --target-slot production

---

Reference Architectures

Web Application (3-Tier)

WAF Alignment:

Component	Reliability	Security	Cost	Operations	Performance
Front Door	Global LB, failover	WAF, DDoS	Pay per request	Managed	Edge caching
App Service	Multi-instance	Managed identity	Reserved capacity	Deployment slots	Auto-scale
SQL Database	Geo-replication	TDE, firewall	DTU/vCore choice	Auto-tuning	Read replicas
Redis Cache	Clustering	Private endpoint	Right-size tier	Managed	Sub-ms latency

---

Event-Driven Architecture

---

Microservices on AKS

---

Anti-Patterns to Avoid

Anti-Pattern 1: Monolithic Reliability

Problem: Adding redundancy only at the infrastructure level.

Issues:

• Database is single point of failure
• No circuit breakers between components
• Shared state prevents true scaling

Solution: Design for failure at every layer with proper isolation.

---

Anti-Pattern 2: Security Afterthought

Problem: Adding security controls after architecture is complete.

Stage	Anti-Pattern	Best Practice
Design	No security requirements	Threat modeling
Development	Hardcoded secrets	Key Vault integration
Deployment	Public endpoints	Private endpoints
Operations	No monitoring	Security monitoring

Solution: Shift-left security - integrate from the start.

---

Anti-Pattern 3: Over-Engineering for Scale

Problem: Building for millions of users on day one.

Solution: Start simple, design for evolution, scale when needed.

---

Anti-Pattern 4: Ignoring Operational Costs

Problem: Focusing only on infrastructure costs.

Cost Type	Often Ignored	Impact
Engineering time	Complex architectures	High
Incident response	Poor monitoring	High
Technical debt	Quick fixes	Medium
Training	New technologies	Medium

Solution: Consider total cost of ownership, not just Azure spend.

---

Anti-Pattern 5: Copy-Paste Architecture

Problem: Using reference architectures without adaptation.

Issues:

• May not fit your scale
• May not fit your team's skills
• May include unnecessary components
• May miss your specific requirements

Solution: Use reference architectures as starting points, adapt to your context.

---

Decision Frameworks

Architecture Decision Record (ADR)

# ADR-001: Database Selection

## Status
Accepted

## Context
We need a database for our e-commerce application that handles:
- 10,000 orders/day
- Product catalog of 100,000 items
- User sessions and carts

## Decision
Use Azure SQL Database with:
- Business Critical tier for production
- Geo-replication to secondary region
- Read replicas for reporting

## Consequences

### Positive
- Strong consistency for transactions
- Familiar SQL interface
- Built-in HA and DR

### Negative
- Higher cost than alternatives
- Schema changes require planning
- Limited horizontal scaling

### Tradeoffs
- Chose reliability over cost
- Chose consistency over flexibility

## Alternatives Considered
- Cosmos DB: Better scaling, but eventual consistency concerns
- PostgreSQL on VM: Lower cost, but operational overhead

---

Decision Tree: Compute Selection

---

Decision Tree: Data Store Selection

---

Checklist: Cross-Pillar Review

Before Design

• Identify business priorities (which pillars matter most?)
• Define acceptable tradeoffs
• Document constraints (budget, timeline, skills)
• Review similar reference architectures

During Design

• Evaluate each major decision against all pillars
• Document tradeoffs in ADRs
• Identify single points of failure
• Plan for day-2 operations

After Design

• Conduct WAF assessment
• Review with security team
• Estimate costs
• Plan monitoring strategy
• Document operational runbooks

---

Key Takeaways

1. Tradeoffs are inevitable: Understand and document them
2. Context matters: Reference architectures need adaptation
3. Avoid anti-patterns: Learn from common mistakes
4. Use decision frameworks: Make informed, documented choices
5. Balance all pillars: Don't optimize one at the expense of others

---

Resources

• Azure Architecture Center
• Cloud Design Patterns
• Reference Architectures
• Architecture Decision Records
• Well-Architected Framework