1.6 Essential characteristics, and RAS

Describes the cloud landscape as of August 2026

What this is and why it exists

A brochure says "reliable and scalable". A checklist asks: which of the five essential characteristics does this offering actually have, and what does its reliability, availability and serviceability really promise? This lesson turns you from a brochure reader into a checklist user.

The vocabulary

  • On-demand self-service — resources by API or portal, no humans in the loop.
  • Broad network access — reachable over standard networks from standard devices.
  • Resource pooling — shared hardware, many tenants, location abstracted.
  • Rapid elasticity — scale out and back fast enough to follow demand.
  • Measured service — metered use, visible to you, billed from the meter.
  • Reliability — how rarely the thing breaks mid-task.
  • Availability — the fraction of time it answers at all.
  • Serviceability — how quickly and painlessly it can be fixed or maintained.

The mental model

The five characteristics are a test, not a description. Apply them to anything sold as "cloud": a hosting company that provisions your server by support ticket in two days fails self-service; a "private cloud" that cannot shrink fails elasticity; a flat-fee service with no usage visibility fails measured service. Whatever fails the test may still be useful — it is not cloud, and it will not behave like cloud when you lean on it.

RAS is the second checklist, and each letter is bought separately. Reliability is redundancy in the components; availability is redundancy in the whole path; serviceability is design that lets repairs happen without stopping the world. Each costs money, and a provider's real offer is which of the three they spend on — read their service commitments with the three words separated.

Where a cloud provider genuinely beats a traditional IT service provider: elasticity nobody can match from a fixed data centre, and global reach from one console. The two places it does not: steady heavy workloads (the pooling premium buys flexibility you are not using), and deep customisation (shared platforms standardise or die). And the honest risk list to hold beside any provider's pitch: lock-in that grows with every proprietary service used, egress charges on the way out, opacity while their outage is being fixed on their schedule, and shared fate — their bad day is yours, together with thousands of strangers'.

What you should now be able to explain or do

Test any offering against the five characteristics and say which it fails. Split "reliable" into R, A and S and say what each costs. Name where cloud beats traditional IT, the two places it does not, and the four honest risks.

Check yourself

On-demand self-service — a human in the loop and a two-day wait is the opposite of it.

Reliability: how rarely it breaks. Availability: how much of the time it answers. Serviceability: how painlessly it can be fixed while running.

Steady, predictable heavy load — and deep customisation that a shared platform cannot offer.

Pooling means the provider's outage lands on all tenants at once — your bad day is scheduled by their incident, and you wait in the dark with everyone else.

Go deeper

Back to Essential characteristics, and RAS: work through the checklist