Azure architecture design patterns - proven solutions to common challenges

August 31
BULGARIA AZURE BOOTCAMP IS POWERED BY:
Cloud Architecture Design Patterns
Proven Solutions to Common Challenges

Thanks to our Sponsors:
General Sponsors:
Technology Partner:

• Software Architect @
o 18+ years professional experience
• Microsoft Azure MVP
• External Expert Horizon 2020, Eurostars-Eureka
• External Expert InnoFund Denmark, RIF Cyprus
• Business Interests
o Web Development, SOA, Integration
o IoT, Machine Learning, Computer Intelligence
o Security & Performance Optimization
• Contact
ivelin.andreev@icb.bg
www.linkedin.com/in/ivelin
www.slideshare.net/ivoandreev
Speaker Bio

Takeaways
Azure Application Architecture Guide
• https://docs.microsoft.com/en-us/azure/architecture/guide/
Cloud Design Patterns for Azure (Series)
• Design and Implementation
• Availability and Resilience
• Data Management and Performance

Architecture be like
“bird’s eye view”
Implementation be like
“close-up”

Shortly after build completion
“the results”

Cloud Architecture Design Challenges
Availability
Data Management
Consistency
Messaging
Management & Monitoring
Performance & Scalability
Recover from Failures
Security
The time a system is functional and working (SLA Uptime %)
Data on multiple locations, performance and consistency
Predictable behaviour, reusable decisions, maintainability
Required by the distributed loosely coupled nature of the cloud
Expose runtime and debug information
Responsiveness within time unit, handle load w/o impact
Detecting failures, and recovering quickly and efficiently
Prevent malicious or accidental issues outside the designed usage

Management & Monitoring Patterns
Anti-corruption Layer
• Adapter layer between 2 subsystems to
isolate and translate semantics
• Consider
o Data consistency
o Extra maintenance point
o Permanent vs retiring layers
o Possible overhead and scalability challenges
o Interoperation with legacy system requires shared semantics
• Not Suitable
o No significant semantic differences between systems
Gateway Offloading Pattern
• Offload shared or specialized service
functionality to an API gateway / proxy
• Consider
o Central handling of shared features
o Maintain shared features in multiple places
o Delegate certain responsibilities to specialized team (i.e. security)
o Secure appropriate scaling, avoid bottlenecks
• Not Suitable
o When introducing coupling between services
o No business logic shall be offloaded (keep reusable)

When to use Messaging Services in Azure?
Event Grid
• Event-driven reactive
programming
Key Points
• Cheap (€0.5 per 1M)
• At least once delivery
• Does not deliver data
• Order delivery not possible
• Push-based delivery
Reason to Use
• React on event
Event Hub
• Big data and telemetry
pipeline
Key Points
• Semi-cheap (€9.2/month)
• Low latency, millions of
events per sec.
Reason to Use
• Telemetry streaming
Service Bus
• High value secure
messaging and control
Key Points
• 13M free, €0.0114 unit/h
• Batches, filters, duplicate
detection, transactions
• Pull-based delivery
• Order delivery
Reason to Use
• X-system transactions
https://docs.microsoft.com/en-us/azure/event-grid/compare-messaging-services

Claim-Check Pattern
• Split large messages into claim-payload to
protect message bus from overwhelming
• Consider
o Custom logic to apply pattern for large messages only
o Delete the message data after consuming
• Not Suitable
o Overhead for small messages
Messaging Patterns
Asynch Request-Reply
• Decouple backend processing from a frontend host
• Consider
o Validate request prior to starting a long running task
o API endpoint shall return:
• Location – a place where to poll, includes CorrelationID
• Retry Interval – when to retry for new status to reduce unnecessary load
o Callback endpoint could be used instead
• Not Suitable
o When response latency is important
o When callback, WebSockets or SignalR are possiblehttps://github.com/SeanFeldman/ServiceBus.AttachmentPlugin

Availability Patterns
Throttling
• Control resource consumption to allow
system functioning under extreme load
• Consider
o Reject requests from some users (service time or last)
o Degrade Quality of Service (bandwidth, compression, time)
o Delay operation (i.e. queue processing time)
o Provide specific Throttling error code to denied user
o Quickly detect high demand and apply throttling
Health Endpoint Monitoring
• Functional check of an application using
external endpoint on given interval
• Consider
o Tools (App Insights Web Tests, System Center Ops Manager)
o Get response time to a health verification endpoint
o Analyse results (Alive != Working, response body)
o Consider action in case of failure (i.e. restart)
o Secure the endpoint – authentication, IP filter

Two Types of Azure Queue Services?
Storage Queue
• Part of Azure storage infrastructure
• Simple Get/Put/Peek interface
Key Points
• No message ordering guarantee
• Intended for decoupling for scalability scenarios
• Scheduled delivery and poison message support
• No duplicate detection
• No session support
• Max message size 64KB
Service Bus Queue
• Part of Azure Messaging infrastructure
• Publish–subscribe model
Key Points
• Message ordering guarantee
• At least once / At most once delivery
• Transactions within a queue
• Scheduled delivery and poison message support
• Duplicate detection based on MessageId
• Session support for message processing affinity
• Max message size 1MB
https://docs.microsoft.com/en-us/azure/event-grid/compare-messaging-services

Pipes and Filters Integration
• Decompose a complex task in separate
individually scalable elements
• Suitable – reusable pipeline filters; avoid
bottleneck filters; breakable processing;
flexibility to reorder steps; context sharing
Consistent Design Patterns
• Sample Implementation
o Message Queue (i.e. AZ Service Bus) receives raw message
o Filter task (i.e. AZ Function App) listens and transforms message
o Message enqueued on next queue
o Until final message is built
• Not suitable – processing steps are not
independent (i.e. bad design) or transactional;
huge context may make the process
inefficient; not sufficient scalability of
underlying resources (i.e. DB)
https://github.com/mspnp/cloud-design-patterns/tree/master/pipes-and-filters

Gateway Aggregation
• Aggregate individual requests to one.
Improve performance on high-latency
network
• Suitable
o CorrelationID identification of original calls
o Partial response on service failure
o Caching
o No service coupling for backend services
o Near to backend to reduce latency
• Not Suitable
o Need to reduce calls to backend (i.e. with batch handling)
o Application is near to backend and latency is practically zero
Command and Query Request Segregation
• Separate Read and Create operations to a datastore
for performance, scalability and security.
• Suitable
o Enqueue async commands
o Separate R/W databases, individual scaling R/W endpoints
• Not suitable
o Simple domain and business rules;
o When CRUD interface implementation is sufficient

Ambassador Proxy
• External process sends requests on behalf
of a consumer service or application
• Suitable
o Offload common topics on same host as a sidecar;
o Extend legacy or not modifiable apps
• Not suitable
o Latency overhead unacceptable
o Context sharing required
o Reusability cannot be achieved
Strangler Façade
• Incrementally migrate a legacy system,
gradually replacing pieces of functionality
• Suitable
o Avoid bottleneck façade;
o Assure common resources are accessible
• Not suitable
o Cannot intercept backend calls;
o No complex wholesale replacement

Sidecar Pattern
• Deploy components in a separate process to
provide isolation and encapsulation
• i.e. Infrastructure Sidecar - monitors main app
• Consider
o Suitable interprocess communication (reliability, performance)
o Service or daemon instead of sidecar
• Suitable
o Heterogeneous languages
o Different teams or entity owns a component
o Independent update of components shall be enabled
• Not Suitable
o Performance of communication is critical
o Small solutions where the design benefit is not worth
o Individual scaling requirements may require a service

Circuit Breaker Pattern
• Prevent application from repeatedly trying
to execute remote service, likely to fail.
• Suitable – temporary errors due to
timeout, network issues, high resource
utilization
o Closed – request routed to endpoint (Threshold)
o Open – request fails immediately (Timer)
o Half-open - limited number of requests are monitored to decide
on Open/Closed
• Challenges
o Resource differentiation and resource abstraction
o Manual override to open state
o Enqueue failed requests for reprocessing
• Not Suitable - local/in-memory resources
Resiliency Patterns

Resiliency Patterns
Compensating Transaction Pattern
• Undo the work from an eventually
consistent transaction from series of steps.
• Challenges
o Simple replace of previous state is rarely possible
o Record information on each step on how steps can be undone.
o Undo might not be doable in exactly the reverse order
o Consider retry logic to try avoiding compensating transactions
o Restore first the more sensitive to changes entities
o Compensating transaction shall be idempotent (repeatable)
• Suitable
o Avoid distributed transactions with eventual consistency
o Undo failed steps by performing the reverse action
• Not Suitable
o Try to avoid the complications if possible

Valet Key Pattern
• Token for restricted access to resource to offload
workload from the main application
• Consider
o Manage key validation, use short key expiration
o Key only for the required operation
o Audit all operations; deliver the key securely
o Provide the client with a key or token that the data store can validate.
• Not Suitable
o When action is required before sending to datastore.
o Limit user behavior – i.e. subscribe to events of resource to validate
Gatekeeper Pattern
• Limit attack surface by using dedicated
instance to sanitize and validate requests
• Challenges
o The backend host shall not expose unprotected endpoints
o May introduce single point of failure or performance hit
o Shall not perform actions other than sanitization
• Suitable
o Services with high degree of sensitive data
o Centralize validation
Security Patterns

Resiliency Patterns
Queue-Based Load Leveling
• Use a buffer queue between a task and a
service to smooth demand peaks.
• Suitable
o Maximize availability when overloading is expected
o Maximize scalability as Tasks and Services grow independently
o Reasonable cost – services scale on load, rather than max load
• Challenges
o Communication is one-way. When response is needed, use Async
request-reply with correlation ID (i.e. sequence Nr)
o Control the rate of consuming messages to avoid overload of
underlying resources (i.e. scaling consumers and DB contention)
• Not Suitable
o When minimal latency is critical

Performance and Scalability Patterns
Materialized View Pattern
• Prepopulated view in the necessary format
to support efficient querying
• Suitable
o Performance improvement; Limited data access
o Query simplification – ignore data complexity RDBMS + NOSQL
• Challenges
o Reusability – likely to have multiple hits
o Disposability – can be regenerated at any time
o Variability – can vary on user or query parameters
o Consistency – data may become outdated
o Regeneration – update on new data, manual trigger
• Not Suitable
o Easy to read source data
o Data changes very quickly and requires lots of regenerations
o Consistency is a priority
o Domain Driven Design – behaviour w/o data (as in microservices)

Azure architecture design patterns - proven solutions to common challenges

More Related Content

What's hot (20)

Similar to Azure architecture design patterns - proven solutions to common challenges (20)

More from Ivo Andreev (20)

Recently uploaded (20)

Azure architecture design patterns - proven solutions to common challenges