Cloud Architecture Guide - Microsoft

[kymr]

Ref

• https://docs.microsoft.com/en-us/azure/architecture/guide/

[kymr]

Overview

• N-Tier
• Web-Queue-Worker
• Microservices
• CQRS
• Event-driven architecture
• Big Data
• Big Compute

Consider

• Complexity
• Asynchronous messaging and eventual consistency
• Inter-service communication
• Manageability

[kymr]

N-tier Archituecture

Benefits

• portability (cloud vs on-premises)
• less learning curve
• traditional
• heterogeneous

Challenges

• just CRUD
• not independent deployment
• IaaS is more work
• security of large system

Best Practices

• auto scaling
• async messaging
• cache
• DB for HA
• firewall in front of FE
• subnet for each tier
• access control to data

Additional consideration

• more tiers than 3
• scalability, reliability, security
• two or more NVA for HA
• bastion for security
• regional failover

[kymr]

Web-Queue-Worker

Benefits

• simple
• operation costs
• SoC
• decoupled fe & worker
• can be scaled independently (fe & worker)

Challenges

• careful design
• hidden dependencies

Best Practices

• well designed apis
• auto scaling
• cache
• CDN for static
• polyglot persistence
• partition data

Additional consideration

• workers for resource intensive tasks
• auto-scale policies (schedule vs metrics)
• separate App service

[kymr]

Microservices

Benefits

• Independent deployments
• independent developments
• small, focused teams
• fault isolation
• mixed tech stack
• granular scaling

challenges

• complexity
• development and test
• lack of governance
• network congestion and latency
• data integrity
• management
• versioning
• skillset

Best practices

• domain driven
• decentralize
• private db
• communicate through well designed apis
• decoupling
• crosscutting concerns
• loose coupling & high cohesion
• isolate failures

[kymr]

CQRS

Benefits

• independently scaling
• optimized data schemas
• security
• SoC
• simpler queries

Challenges

• Complexity
• Messaging
• Eventual consistency

Best practices

• CQRS
• Event sourcing
• materialized views

[kymr]

Event driven

Benefits

• decoupled
• easy to add new consumers (no point to point integration)
• consumer respond immediately
• scalable distributed
• independent views

Challenges

• guaranteed delivery
• in order & exactly once

[kymr]

Big-data

Benefits

• Technology choice
• performance (parallelism)
• elastic scale
• interoperability

Challenges

• Complexity
• skillsets
• technology maturity
• security

Best practices

• Leverage parallelism
• partition data
• Apply schema-on-read semantics
• process data in place
• balance utilization and time costs
• separate cluster resources
• orchestrate data ingestion
• scrub sensitive data early

[kymr]

IOT

• field gateway
• cloud gateway
• stream processors
• device registry
• provisioning api
• command and control

[kymr]

Big compute

Benefits

• high performance
• can harness many cores
• super hardware & InfiniBand Networks

Challenges

• VM Infrastructure
• volumn
• provisioning many cores timely manner
• For tightly coupled tasks, core optimization

[kymr]

Compute Options

• IaaS
• PaaS
• FaaS
• VM
• App Service
• Service Fabric
• Azure Container Service
• Azure Container instances
• Azure Functions
• Azure Batch
• Cloud Services

Evaluation Aspect

• Feature set
• Service limits
• Cost
• SLA
• Regional availability
• Developer ecosystem and skills

Criteria

• Hosting model
  • application composition
  • density
  • minumum nodes
  • state management
  • web hosting
  • can be deployed to VNet
  • hybrid connectivity
• DevOps
  • local debugging
  • programming model
  • application update
• Scalability
  • auto scaling
  • load balancer
  • scale limit
• Availability
  • SLA
  • multi region failover
• Other
  • SSL
  • Cost
  • suitable architecture

[kymr]

Data Store

• RDBMS
• Key/Value store
• Document database
• Graph Database
• Column-family database
• Data Analytics
• Search Engine Database
• Time Series Database
• Object Storage
• Shared Files

Criteria

• Functional
  • Data Format
  • Data Size
  • Scale and Structure
  • Data relationships
  • Consistent model
  • Schema flexibility
  • Concurrency
  • Data movement
  • Data lifecycle
  • others
• Non-Functional
  • Performance & Scalability
  • Reliability
  • Replication
  • Liimits
• Management & Cost
  • Managed Service
  • Region availability
  • Portability
  • Licensing
  • Overall cost
  • Cost effectiveness
• Security
  • Security
  • Auditing
  • networking requirements
• DevOps
  • Skill set
  • Clients

[kymr]

Ten design principles

• Design for self healing
• Make all things redundant
• Minimize coordination
• Design to scale out
• Partition around limits
• Design for operations
• Use managed services
• Use the best data store for the job
• Design for evolution
• Build for the needs of business

[kymr]

Design for self healing

• Design your application to be self healing when failures occur
  • detect failures
  • respond to failures gracefully
  • log and monitor failures, to give operational insight

Recommendations

• Retry failed operations
• Protect failing remote services (Circuit breaker)
• Isolate critical resources (Bulkhead)
• Perform load leveling
• Fail over
• Compensate failed transactions
• Checkpoint long running transactions
• Degrade gracefully
• Throttle clients
• Block bad actors
• Use leader election
• Test with fault-injection
• Embrace chaos engineering

[kymr]

Make all things rudundant

• Build redundancy into your application, to avoid having single point of failure

Recommendations

• Consider business requirements
• Place VMs behind a load balancer
• Replicate databases
• Enable geo-replication
• Partition for availability
• Deploy to more than one region
• Synchronize front and backend failover
• Use automatic failover but manual failback
• Include redundancy for Traffic manager

[kymr]

Minimize coordination

• Minimize coordination between application services to archive scalability

Recommendations

• Embrace eventual consistency
• Use domain events to synchronize state
• Consider patterns such as CQRS and event sourcing
• Partition data
• Design idempotent operations
• Use asynchronous parallel processing
• Use optimistic concurrency when possible
• Consider MapReduce or other parallel, distributed algorithms
• Use leader election for coordination

[kymr]

Design to scale out

• Design your application so that it can scale horizontally

Recommendations

• Avoid instance stickiness
• Identify bottlenecks
• Decompose workload by scalability requirements
• Offload resource-intensive tasks
• Use built-in autoscaling features
• Consider aggressive autoscaling for critical workloads
• Design for scale in

[kymr]

Partition around limits

• Use partitioning to work around database, network, and compute limits

Recommendations

• Partition different parts of the application
• Design the partition key to avoid hot spots
• Partition around Azure subscription and service limits
• Partition at different levels

[kymr]

Design for operations

• Make all things observable
• Instrument for monitoring
• Instrument for root cause analysis
• Use distributed tracing
• Standardize logs and metrics
• Automate management tasks
• Treat configuration as code

[kymr]

Use the best data store for the job

• Don't use a relational database for everything
• Embrace polyglot persistence
• Consider the type of data
• Prefer availability over (strong) consistency
• Consider the skill set of the development team
• Use compensating transactions
• Look at bounded contexts

[kymr]

Design for evolution

• Enforce high cohesion and loose coupling
• Encapsulate domain knowledge
• Use asynchronous messaging
• Don't build domain knowledge into a gateway
• Expose open interfaces
• Design and test against service contracts
• Abstract infrastructure away from domain logic
• Offload cross-cutting concerns to a separate service
• Deploy services independently