Learn how to design applications and implement common design patterns in Windows Azure.
Application architecture overviews
This article focuses on the architectural considerations for designing scalable and reliable systems. It provides detailed guidance about the following areas:
- Decomposing an application workload
- Establishing a lifecycle model
- Establishing an availability model and plan
- Identifying failure points and failure modes
- Identifying resiliency patterns and resiliency considerations
- Designing for operations
Windows Azure provides many features that allow you to address the key issues encountered when designing a multitenant system, including isolation, storage, connection and security services, networking services, and resource provisioning. This overview describes how Windows Azure supports multitenant apps and introduces a detailed multitenant reference implementation.
The primary goal of a load test is to simulate many users accessing a web application at the same time. Windows Azure provides value to your application in its ability to handle an elastic work load. This overview describes how to apply Windows Azure features to reduce your testing costs by leveraging the elastic scaling capabilities in Windows Azure. The article introduces a reference implementation that leverages Windows Azure and Visual Studio Load Test.
Design patterns: Data
Command Query Responsibility Segregation (CQRS)
The Command Query Responsibility Segregation (CQRS) pattern is a higher level pattern that separates database read and write operations into separate services. In the pattern, operations should be either commands or queries. A query returns data and does not alter the state of the object; a command changes the state of an object but does not return any data. The benefit is that you have a better understanding what does, and what does not, change the state in your system.
Design patterns: Fault tolerance
Transient error handling
Transient faults are errors that occur because of some temporary condition such as network connectivity issues or service unavailability. Typically, if you retry the operation that resulted in a transient error a short time later, you find that the error has disappeared. The Transient Fault Handling Application Block encapsulates information about the transient faults that can occur when you use the SQL Database, Service Bus or Windows Azure Storage.
Managing database throttling
SQL Database provides a large-scale, multi-tenant database service on shared resources. To provide a good experience to all customers, SQL Database sometimes throttles work or closes connections to prevent a machine from becoming overloaded. There are several techniques you can use to ensure that your application is not negatively impacted by throttling
Design patterns: Messaging
Queues: guarantee message delivery and distribute work
You can use queues in Windows Azure to support asynchronous communication between components. A component in an application can post a message to a queue. Other components can pick up the message and process it. The queue provides durable persistence between components, as well as benefits for load- leveling, load-balancing, and scaling.
Publish/subscribe is a messaging model where all subscribed components receive a notification when a message arrives. Windows Azure Topics and Subscriptions provide a pub/sub messaging model. Messages are sent to a topic in the same way as they are sent to a queue. However, messages are not received from the topic directly; they are received from subscriptions.
Design patterns: Scaling
One of the benefits of a Windows Azure cloud service application is that you can easily scale individual components as your application's usage changes. The Autoscaling Application Block from the Microsoft Enterprise Library 5.0 Integration Pack for Windows Azure provides tools that let you automatically scale your cloud service. You can use performance counters to understand your app's performance, and then write rules that will automatically scale your app to adjust for specified targets and thresholds.
Design patterns: State
Store state information in caching
Stateless apps require state to be cached and retrieved from durable stores. As an example, ASP.NET cookies can be used to store state. Those cookies can be stored in Caching, globally available to all web role instances.