High availability and scalability
Two of the cloud benefits AZ-900 names are high availability and scalability. They are related but not the same thing, and the exam likes to test the difference.
High availability
High availability means a service stays up and usable with as little downtime as possible, even when parts of the system fail. Azure achieves this with redundancy: extra copies of servers, power and networking, spread across separate locations.
Availability is promised in a service-level agreement (SLA), as a percentage of uptime per month:
| SLA | Maximum downtime per month (about) |
|---|---|
| 99% | 7 hours 18 minutes |
| 99.9% | 43 minutes |
| 99.95% | 22 minutes |
| 99.99% | 4 minutes 22 seconds |
| 99.999% | 26 seconds |
Each extra "nine" cuts the allowed downtime by about ten times. You can raise the availability of your own solution by running multiple instances, for example across availability zones.
Composite SLAs
When an application depends on several services, all of them must be up for the application to work, so its availability is the SLAs multiplied together. A web app at 99.95% that needs a database at 99.99% has a composite SLA of 0.9995 × 0.9999 ≈ 99.94%: lower than either service on its own. Adding dependencies lowers the composite SLA; adding redundant copies raises it.
Scalability
Scalability is the ability to adjust resources to meet demand. You add resources when demand rises and remove them when it falls, so you pay only for what you need.
There are two ways to scale:
- Vertical scaling (scale up / down): give an existing resource more power, such as more CPU or memory on a virtual machine.
- Horizontal scaling (scale out / in): add or remove instances, such as going from two virtual machines to ten.
Elasticity
When scaling happens automatically in response to demand, it is often called elasticity. An online shop that automatically adds web servers during a sale and removes them afterwards is elastic.