Why the cloud: availability, scalability, reliability, predictability, security and manageability

Why this matters

"Move it to the cloud" is often said as if the move itself made things better. It does not. The cloud offers a set of distinct benefits, and each one comes from a specific feature that someone has to choose and set up. A manager who knows the difference between availability and reliability can ask the right question when a supplier promises both. A salesperson can say which feature delivers which benefit instead of promising everything. A junior administrator can tell a capacity problem from a resilience problem and reach for the right tool.

The words here sound alike, and the exam relies on that. Scalability is not reliability. Cost predictability is not performance predictability. Governance is not security. Management of the cloud is not management in the cloud. This lesson takes the benefits in four pairs and ties each to the Azure features that deliver it, so that a scenario can be matched to the benefit it describes.

The lesson

High availability and scalability

High availability means a service stays accessible when one of its components fails. The way to get it is to remove every single point of failure.

• Run an application on several virtual machines instead of one, so users can still reach it when one machine fails.
• Put Azure Load Balancer in front of them. It sends traffic only to healthy instances, so a failed VM simply stops receiving requests.
• Spread the VMs across availability zones: physically separate locations within one region, each with its own power, cooling and networking. The application then survives the loss of a whole datacenter. Lesson 5 covers zones in detail.

Making a single VM larger does not improve availability. It is still one machine, and still a single point of failure.

Microsoft states its availability commitments in a service-level agreement (SLA). An SLA describes Microsoft's commitment to a service's uptime and connectivity, and usually the service credits a customer can claim if that commitment is missed. It does not give prices, security duties or the list of regions. When an application depends on several services and fails if any one of them is down, its expected availability is the product of their SLAs, which is lower than any one of them alone. As an illustration, two services each promising 99.9% uptime give roughly 99.8% when the application needs both.

Scalability is the ability to adjust resources to meet demand. A retailer whose traffic triples during a yearly sale adds capacity for the sale and removes it afterwards, paying only for what it uses. There are two directions:

Autoscaling makes horizontal scaling automatic. A web application adds instances when CPU use is high and removes them when demand drops, with nobody stepping in. The cloud's ability to grow and shrink like this is often called elasticity.

The speed is the point. On premises, adding capacity takes weeks, because hardware must be ordered and installed. In Azure, new compute and storage can be provisioned in minutes from Microsoft's existing capacity. A ticket site expecting a surge for one afternoon can add capacity for that afternoon and release it afterwards.

Reliability and predictability

Reliability is the ability of a system to recover from failures and carry on working. Where availability is about staying reachable through a component failure, reliability is about surviving and recovering from larger events.

The cloud helps because of its decentralised design and global footprint. Azure has regions around the world, so a company can deploy a copy of its application in a second region and fail over to it if a disaster strikes the first. Azure does not copy every resource to every other region automatically. Replication across regions has to be designed or configured.

Storage shows the same idea for data (lesson 9 has the details):

• Locally redundant storage (LRS) keeps copies within one datacenter.
• Zone-redundant storage (ZRS) copies data across availability zones in one region. It survives the loss of a datacenter, but not the loss of the whole region.
• Geo-redundant storage (GRS) also copies data to a secondary region far from the primary, so the data survives the loss of the primary region.

Predictability comes in two halves, and the exam treats them separately.

Performance predictability means a workload can be trusted to perform well as its demand changes. Two features deliver it together: autoscaling adds resources as demand grows, and load balancing spreads requests across healthy instances. An online store whose traffic rises unpredictably can still give customers consistent page load times.

Cost predictability means knowing in advance what a workload will cost. Azure supports it before and after deployment:

• Before: the Azure pricing calculator estimates the monthly cost of a planned deployment before anything is built.
• After: Microsoft Cost Management reports what deployed resources have actually cost so far, shows usage and spending trends with forecasts, and supports budgets with alerts as spending nears a limit.

Azure Advisor also recommends cost savings, but only for resources that already exist; it cannot price something not yet built. Lessons 12 and 16 cover these tools. Note that improving availability, for example by spreading VMs across zones, usually adds cost rather than making cost predictable.

Security and governance benefits

Security. Microsoft invests in security at a scale few companies can match, and Azure customers inherit the results. Under the shared responsibility model (lesson 1), Microsoft always handles the physical security of its datacenters and the physical network, hosts and hardware. It also builds protection against distributed denial-of-service (DDoS) attacks into the platform, a defence that would be costly for one company to build alone. A company that cannot keep up with new threats in its own datacenter gains these tools and this expertise by moving.

The cloud also lets a company choose how much security work it keeps:

• With IaaS, such as Azure Virtual Machines, the customer controls and secures the operating system, including its patches. That is the most security control available in the cloud.
• With PaaS, such as Azure App Service, Microsoft patches the operating system and platform. The company gives up that control in exchange for less work.

Whatever the choice, some duties never pass to Microsoft. The customer always classifies its data and manages its user accounts and access, and with IaaS and PaaS it also sets its own firewall rules. Moving to Azure does not hand over all security responsibility, and it does not make applications free of vulnerabilities.

Governance means applying the organisation's rules consistently to everything it builds. The cloud makes this enforceable rather than a matter of hope.

• Azure Policy evaluates resources against rules. It can deny the creation of anything that breaks a rule, such as a resource outside the approved regions. It also evaluates existing resources and reports which are non-compliant, for example those missing a required tag. Lesson 13 covers it.
• Management groups sit above subscriptions. Policies and access assigned to a management group are inherited by every subscription beneath it, so a company with 30 subscriptions applies its rules once. Lesson 6 explains the hierarchy.
• Templates, such as ARM templates and Bicep files, create every resource with the same reviewed settings. They make deployments repeatable and leave a record an auditor can check. A VM built by hand in the portal invites inconsistent settings that are hard to prove. Lesson 15 covers templates.

Do not confuse Azure Policy with Azure role-based access control (RBAC). RBAC decides which people can perform which actions. Policy decides what the resources themselves may look like, such as where they may be deployed, whoever creates them.

Compliance is the part of governance that faces outward. Two points are tested:

• The Microsoft Service Trust Portal publishes Microsoft's audit reports, certifications and compliance documents, which a regulated company can give to its auditors.
• Customers choose the region where they deploy resources and store data, which supports data residency rules such as keeping customer data within one country. Tags, by contrast, are metadata for organising and reporting; they do not control where data is kept.

Manageability in the cloud

Manageability means the cloud gives the customer ways to monitor, configure and automate its resources. Microsoft splits it into two kinds, and the exam asks which is which.

Management of the cloud is about what the platform can do with the resources themselves:

• scale them automatically as demand changes;
• deploy them from preconfigured templates;
• monitor their health and replace failing resources, as a scale set does with automatic instance repairs;
• raise alerts based on metrics. Azure Monitor metric alert rules can notify the operations team when a production VM's CPU use stays above a threshold. Tags and resource locks do nothing of the sort.

Management in the cloud is about the tools and interfaces the customer uses to manage the environment:

• the Azure portal, a web-based console that needs nothing more than a browser;
• the Azure CLI and Azure PowerShell, whose commands can be combined into scripts, so the same set of resources can be created every week without clicking through screens;
• REST APIs, which the portal and the command-line tools all use underneath.

Lesson 14 covers these tools, including Azure Arc, which extends Azure management to resources outside Azure. Arc is not the browser interface.

A useful test: if the example is something the resources do for you, it is management of the cloud. If it is something you use to do the work, it is management in the cloud. Manageability does not mean Microsoft manages everything with no customer access, and it is not the same as high availability.

What the exam is really asking

• Availability versus reliability. Several VMs behind a load balancer, or across zones, keep a service reachable through a failure: high availability. A copy in a second region to survive a regional disaster: reliability.
• Scalability versus reliability. Matching capacity to load is scalability. Recovering from failure is reliability.
• Up, down, out, in. Larger or smaller machine is vertical (up, down). More or fewer machines is horizontal (out, in). Autoscaling normally means horizontal.
• SLAs. An SLA is a commitment to uptime and connectivity. A chain of dependent services has a lower combined figure than any one of them.
• Two kinds of predictability. Autoscaling and load balancing give performance predictability. The pricing calculator (before) and Cost Management budgets and alerts (after) give cost predictability.
• ZRS versus GRS. Only geo-redundant storage survives the loss of a whole region.
• Policy versus RBAC. Policy controls what resources may be; RBAC controls what people may do. Rules for many subscriptions go on a management group.
• Where audit reports live. The Service Trust Portal, not Azure Service Health, which reports outages and planned maintenance.
• Of versus in. Autoscaling, template deployment, health repairs and metric alerts are management of the cloud. Portal, CLI, PowerShell and APIs are management in the cloud.