Overview of the reliability pillar
Reliability ensures your application can meet the commitments you make to your customers. Architecting resiliency into your application framework ensures your workloads are available and can recover from failures at any scale.
Building for reliability includes:
- Ensuring a highly available architecture
- Recovering from failures such as data loss, major downtime, or ransomware incidents
For more information, explore the following video on diving deeper into Azure workload reliability:
In traditional application development, there has been a focus on increasing the mean time between failures (MTBF). Effort was spent trying to prevent the system from failing. In cloud computing, a different mindset is required, because of several factors:
- Distributed systems are complex, and a failure at one point can potentially cascade throughout the system.
- Costs for cloud environments are kept low through commodity hardware, so occasional hardware failures must be expected.
- Applications often depend on external services, which may become temporarily unavailable or throttle high-volume users.
- Today's users expect an application to be available 24/7 without ever going offline.
All of these factors mean that cloud applications must be designed to expect occasional failures and recover from them. Azure has many resiliency features already built into the platform. For example:
- Azure Storage, SQL Database, and Cosmos DB all provide built-in data replication across availability zones and regions.
- Azure managed disks are automatically placed in different storage scale units to limit the effects of hardware failures.
- Virtual machines (VMs) in an availability set are spread across several fault domains. A fault domain is a group of VMs that share a common power source and network switch. Spreading VMs across fault domains limits the impact of physical hardware failures, network outages, or power interruptions.
- Availability Zones are physically separate locations within each Azure region. Each zone is composed of one or more datacenters equipped with independent power, cooling, and networking infrastructure. With availability zones, you can design and operate applications, and databases that automatically transition between zones without interruption, which ensures resiliency if one zone is affected. For more information, reference Regions and Availability Zones in Azure.
That said, you still need to build resiliency into your application. Resiliency strategies can be applied at all levels of the architecture. Some mitigations are more tactical in nature—for example, retrying a remote call after a transient network failure. Other mitigations are more strategic, such as failing over the entire application to a secondary region. Tactical mitigations can make a large difference. While it's rare for an entire region to experience a disruption, transient problems such as network congestion are more common—so target these issues first. Having the right monitoring and diagnostics is also important, both to detect failures when they happen, and to find the root causes.
When designing an application to be resilient, you must understand your availability requirements. How much downtime is acceptable? The amount of downtime is partly a function of cost. How much will potential downtime cost your business? How much should you invest in making the application highly available?
Topics and best practices
The reliability pillar covers the following topics and best practices to help you build a resilient workload:
|Reliability principles||These critical principles are used as lenses to assess the reliability of an application deployed on Azure.|
|Design for reliability||Consider how systems use Availability Zones, perform scalability, respond to failure, and other strategies that optimize reliability in application design.|
|Resiliency checklist for specific Azure services||Every technology has its own particular failure modes, which you must consider when designing and implementing your application. Use this checklist to review the resiliency considerations for specific Azure services.|
|Target and non-functional requirements||Target and non-functional requirements such as availability targets and recovery targets allow you to measure the uptime and downtime of your workloads. Having clearly defined targets is crucial to have a goal to work and measure against.|
|Resiliency and dependencies||Building failure recovery into the system should be part of the architecture and design phases from the beginning to avoid the risk of failure. Dependencies are required for the application to fully operate.|
|Availability Zones||Availability Zones can be used to spread a solution across multiple zones within a region, allowing for an application to continue functioning when one zone fails.|
|Availability of services||Availability of services across Azure regions depends on a region's type. Azure's general policy on deploying services into any given region is primarily driven by region type, service categories, and customer demand.|
|Availability zone terminology||To better understand regions and availability zones in Azure, it helps to understand key terms or concepts.|
|Best practices||During the architectural phase, focus on implementing practices that meet your business requirements, identify failure points, and minimize the scope of failures.|
|Testing for reliability||Regular testing should be performed as part of each major change to validate existing thresholds, targets, and assumptions.|
|Monitoring for reliability||Get an overall picture of application health. If something fails, you need to know that it failed, when it failed, and why.|
|Reliability patterns||Applications must be designed and implemented to maximize availability.|