Why Cloud?

A purchase order for a server is a promise about a future you cannot see. Someone signs it in the spring for capacity that arrives in the autumn, sized against a forecast written in the winter. By the time the machine is racked, cabled and burned in, the demand that justified it has either failed to appear or outgrown it. The lag between deciding and having was, for most of computing's history, measured in fiscal quarters.

Cloud collapses that lag to minutes, and this — not the invoice — is the real reason companies move. The pitch to the board leans on cost because cost fits on a slide. But the engineers who have lived through both worlds will tell you the thing that changed their working lives was speed: the ability to try an idea on Tuesday instead of budgeting for it next quarter.

Time to value

The interval between deciding to build something and having it serve a real user. Cloud attacks this number harder than it attacks any other.

Consider what a shorter interval actually buys. A feature that used to require a hardware requisition now requires a command. An experiment that would have needed a capital case can be stood up, measured, and — this is the part that matters — torn down again the same afternoon if it fails. Cheap failure is the quiet engine of everything cloud is credited with. You are not paying for servers; you are paying to be wrong faster and less expensively than a competitor who still buys hardware.

In the fictional Campux Retail case, merchandising wants to test a “customers also bought” feature before November. A separate environment lets the team try it without ordering hardware. Define the experiment’s budget, access controls and end date first. If it fails, remove the resources it created and check for retained disks, backups, logs and commitments. Stopping the app alone does not necessarily stop the bill.

Global reach can put an application closer to its users, subject to service availability and data-location requirements. Disaster recovery can keep another recovery location ready without operating a second physical server room. Neither arrives automatically with a subscription. Replication, storage, networking, protection services and recovery tests can cost money before an incident; warm or active standby compute can too. Compare the complete design with the alternatives. See Microsoft’s recovery cost breakdown.

For a new overseas market, first measure where users wait: network round trips, slow application code or database calls. A nearby region or content-delivery layer may help, but brings deployment, consistency, residency and operating decisions. A second region is an architectural choice, not a guarantee that the application becomes faster or safer.

Cost matters too, and §2 will price it precisely. But if you walk into an interview and say the reason for cloud is that it is cheaper, a good interviewer will spend the next ten minutes showing you a bill where it was not. Say instead that it trades a slow, capital-heavy guess for a fast, metered adjustment — and that the speed is what pays for itself. That answer survives contact with reality.

Elasticity means capacity can grow and shrink with demand. Owned hardware can turn resources off or repurpose them, but the purchase remains a commitment. Metered cloud compute offers a different way to pay for changing capacity, provided the application and service support the intended scaling. Campux’s seasonal demand is a fictional example; the numbers below isolate the compute effect.

Numbers make it concrete. Take a unit of production compute costing roughly $150 a month to run continuously.¹ Suppose the storefront needs three units to serve an ordinary month, but ten units to survive the November peak without collapsing. There are two ways to hold that capacity.

Both rows describe cloud compute at the same illustrative rate. Keeping ten units running bills for ten even in quiet months. A reservation or other commitment changes the comparison: you may still owe for a purchase after reducing running capacity. Compare the actual commitment terms, utilization and full workload costs before choosing a strategy. The $11,550 gap is a result of this example, not a forecast for every migration.

What the compute table leaves out

Table 1 priced two cloud strategies against each other at the same metered rate, and on that comparison alone, elasticity already saved about $11,550 a year. That $150-a-unit rate is not a bare hardware cost: a cloud meter bundles in the power, the cooling, the floor space, the spare disks and a slice of someone else's staff, priced into the fee rather than billed to you by name. Owned hardware pays for that same list too, but pays for it directly, all year, sized for the same November peak. The comparison against owned hardware is a separate one, and it needs its own table — the $18,000 in Table 1 is already a cloud number, and cannot be turned into an owned-hardware total just by adding more costs on top of it.

Table 2 lists inputs for a separate total-cost comparison; it does not establish an owned-hardware price. Collect hardware, facilities, labor, support and financing figures rather than reusing the cloud’s $18,000 meter total. On the cloud side include storage, networking, licensing, support, operations and migration costs. Scaling down can reduce eligible compute charges, but retained resources and commitments can continue billing. Some idle capacity is deliberate resilience, rather than waste.

Elasticity you never configure is a discount you never take.

Your task is to make scaling work for the application: choose supported resources, set limits and rules, check quotas, allow provisioning and warm-up time, then test both growth and shrinkage. Some services manage scaling for you; others need configuration. Report a saving only after observing the actual bill and confirming that performance remained acceptable.

A “nine” describes an availability percentage: 99% has two, 99.9% has three and 99.99% has four. For a simple time-based objective, the remainder is a downtime budget. A provider SLA is a contract with its own measurement, conditions and exclusions; its percentage does not describe every failure a customer can experience.

Every additional nine reduces the mathematical downtime budget by a factor of ten. Understand that arithmetic, then check what is actually measured before using a percentage in a design or a promise.

SLA

A service-level agreement is a contractual service commitment with defined conditions and remedies, often service credits.²

An SLA can help you compare commitments and eligible deployment choices. It does not insure your lost sales or establish the application’s end-to-end availability. Credits depend on the agreement’s definitions, exclusions and claim process. Read the applicable terms before promising a remedy.

For the illustrative time-based objective in Table 3, a thirty-day month has 43,200 minutes. A 99.9% objective leaves 43.2 minutes outside the target. Actual SLAs can measure requests or use other definitions, so this arithmetic is neither an outage prediction nor a universal credit threshold.

Figure 1 draws the same fact as a ruler, because a table lets you read the numbers while a ruler makes you feel them: the distance between three nines and four nines is smaller than most people picture, and the distance between any of them and a real outage is larger.

Keep the arithmetic separate from configuration eligibility. Class 11d explores VM availability choices; Class 36c covers explaining an incident. Consult the current VM availability documentation and applicable agreement before quoting a service percentage.

A dependency model is not an application SLA

A checkout request can rely on entry, web, database and storage components. In a simplified model where every component is required and failures are independent, their availability probabilities multiply. Using illustrative probabilities gives 0.9999 × 0.9995 × 0.9999 × 0.999 ≈ 0.998301, or 99.8301%.³

Shared infrastructure, configuration mistakes and deployments can affect several components together. Caching, retries and alternative paths can change which dependencies a request actually needs. Provider SLAs also measure different things. Their percentages cannot simply be multiplied into a promise to your customers.

SLO and SLI

A service-level objective is your workload’s reliability target. A service-level indicator measures the customer experience you use to judge that target.

For Campux, define what a successful checkout means and which requests count. Measure the flow, investigate failures and test recovery. Choose a target with the business, then check whether the architecture and operations can support it. The multiplication illustrates dependency risk; it does not replace that work.

Measure the experience you intend to promise.

A useful migration recommendation names the reasons to wait or choose another design. Check data location and contractual requirements, latency, disconnected operation, application compatibility, staffing and total cost. Already-purchased hardware may affect timing, but depreciation alone does not settle the decision: compare the future costs and benefits of the available choices. Class Three develops this assessment.

In Class One, Campux Retail's finance director stopped you in a corridor with a five-year sum that made owning servers look cheap. He was not being unreasonable; he was being incomplete. This class is where you go back to him — not with a rebuttal, but with his own figures finished.